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:
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:
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).
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.
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.
