I suspect that the problem with the Windows and Mac objects not producing the same results is I suspect something to do with the HBReadRoomEnergyResult object.
In working through that issue on the Windows Deskop, and refining the test script, I noted that the HBLoadMeasures object needed to be manually updated. This tempted me to update manually and try the LoadMeasures again.
I found that I could load the BCL Natural Ventilation Measure using this object and Open Studio ran. The differences in the temperature patterns with and without Natural Ventilation were plausible.
e.g. Floating temperature, no heating, Cooling or Natural Ventilation:
Floating Temperature, No Heating, No Cooling and Natural Ventilation
But, when the energy split is plotted in graphic form:
Heatig and Cooling looks like this:
Heating, Cooling and Natural Ventilation
The storage term in this last graph is, I suspect probably a clue that on the Windows and the Mac this object is not behaving quite as intended?..
Sorry again for the late response here. I am almost done with implementing window-based ventilation within HB-Energy, at which point I can test this more extensively. However, I think I may know why the natural ventilation term of your energy balance has seemed off on your end. If you simply took the default
load_type_ in the “HB Simulation Output” component, EnergyPlus will record the total load supplied by the term, which includes both sensible load + latent load. My guess is that you are really only interested in the sensible portion and you do not particularly care about the latent energy that is added as a result of humid outdoor air (though I’m sure some engineers would be interested in that). In any case, can you try only requesting sensible load like so:
… and let me know if that gets your energy balance to look any better?
Soltuon works, thank you. Documented here: Mac installation puzzlement
I am happy to say that I finished adding components that allow you to set up simple window-based ZoneVentilation for your honeybee models. Once you update with the Versioner component, you can assign ventilation objects directly to your honeybee models and so you shouldn’t have a need for the measure you have been using.
You can see how to use the new components in this updated sample here for the single family home. And you can see that it shows up as a term in the energy balance chart (albeit a small one for Boston’s climate).
Kia ora @chris
I suspect that I am demonstrating my inexperience with Grasshopper List processing, however, I am looking for help with this excellent component.
I planned to feed the two zones into this component with two ventilation control input objects, expecting the first ventilation control object would apply to the first zone and the second would apply to the second zone. Instead, each control object applies to each zone, creating 4 zones, not two.
Hi @MichaelDonn ,
That’s not entirely your inexperience with Grasshopper List processing that is at fault there. I purposefully made the
_rooms input have list access but the
_vent_cntrl have item access because I had originally thought that the case of applying the same controls to all of the rooms of a list would be much more common that applying controls to different rooms.
So my thought was that people could just use Grasshopper data trees or copy the component if they really needed different controls for different rooms. Here is how you could do it with data trees, for example:
But I realize this isn’t nearly as intuitive as putting list access on the
_vent_cntrl and trying to use some “longest list” logic inside of the component. By “longest list” I mean that:
- If one ventilation control is connected, it gets assigned to all rooms.
- If a list of ventilation control objects is connected that has the same length as the rooms, each room gets matched with the ventilation control of the same index.
- If a list of ventilation control objects is connected that has a shorter length than the rooms, each room gets matched with the ventilation control of the same index until it reaches the end of the list and all other rooms get the last ventilation control object.
Let me know if you think this case will be common and I can switch the component to use a logic like this. The main reason why it wasn’t done at first was that it can make the code a little messy and slightly increase the component run time. So I don’t like to implement it everywhere. But I recognize that there are many cases where the increased human time to figure out the data trees or copy the component isn’t worth the savings in computer time so let me know if you think this is one of these cases.
I read this with some relief, but then you offered the use case logic, and I wondered/debated with myself.
My conclusion is “longest list” makes more sense to me.
My rationale is below. I will try to make this a short think piece. (i.e. edit the lengthy thoughts so they are useful)
I have to point out this might be culturally biased in terms of the way I was brought up, not the way people from other Western countries might think. For example, I have, in a Swiss apartment, opened the bedroom window overnight to be able to get to sleep as the apartments around us kept us too warm…
I certainly want to teach people how to model window opening behaviour so it mirrors occupancy (e.g. if there is no-one in the room, the windows are not operated).
I also want to model window size so that cross ventilation when it is windy and stack effect when it is not can be talked about when we are designing the windows ( consistent with our past approach when we had a simulation tool where you just entered the ACH as a fixed rate; then, we insisted students-hand calculated the window opening size required to deliver that rate via wind and stack effect). This your Vent_control object does, though I am still trying to figure out how to explore explicitly the question of how often is it calm and hot, what are the worst indoor temperatures on those days, and how big do the windows need to be to allow the stack effect to function.
Having different temperature goals for different room uses is, I believe, more likely when you are designing a solar passive (not Passiv) house/building. Thus, if I had an office building, I would set the foyer and possibly atrium areas as being allowed to drop to a lower and rise to a higher temperature than the surrounding offices; this would for example allow exploration of the energy and comfort implications of atria as temperature buffers.The ground floor retail in a commercial building would be different again. In the simple box for exploring principles that I am currently developing, the Living/Bedroom split is going to have different goals - I would want students to explore just what happens if I tolerate a higher and lower set point temperature during the day in the bedrooms - or to examine in a heavyweight building or a lightweight well-insulated building does this save energy or cost more?
Thanks, @MichaelDonn . You won me over and, in the last couple of days, I actually found a way to implement this longest list logic in a way that makes the code much cleaner/read-able, which was actually my bigger concern since the increase in runtime is pretty negligible (you aren’t going to feel it until you get up to 1,000 zones or so). So I think I’ll use this longest list logic in a few components that apply properties to rooms:
- HB Window Opening
- HB Apply Load Values
- HB Apply Setpoint Values
- HB Apply Room Schedules
- HB Apply ProgramType
And I opened an issue about it:
But I plan to not touch the components that apply properties to surfaces like the “HB Make Adiabatic” or the “HB Apply Opaque Construction” since these components use a different interpretation of list logic (applying different properties to surfaces that face different orientations if a list is input). If people need the same capabilities with these components, they can use Data Trees.
Hi @chris - thanks for the continued efforts.
(And thankFUL that my case could be understood).
Roll on Monday!
Hey @MichaelDonn ,
I just wanted to let you know that I changed those 5 components in honeybee-grasshopper-energy tp support longest list logic:
So, once you update, you should be able to apply lists of values as you had originally expected.