I’m trying to implement the following model in order to simulate more realistic window opening behaviour of occupants: Rijal, H.B., Tuohy, P., Humphreys, M.A. et al. Build. Simul. (2011) An algorithm to represent occupant use of windows and fans including situation-specific motivations and constraints.
They model the probability of an occupant opening a window via a logit (sigmoid) function based on indoor globe temperature and weighted running mean outdoor temperature. (They also have differing curves for beginning/end/middle of day)
To model this with Grasshopper/Honeybee, I want to:
run a simulation for 1 time step
check the results for the operative temperature
based on this, calculate the probability of a window being opened in the next time step
if yes: enable natural ventilation for the next time step
repeat
I am trying to do this by writing the operative temperature to the sticky dictionary at the end of each step and using it for the next one.
The problem is that, as discussed here, it seems impossible to run a step-by-step simulation in that way.
Does anyone have some advice on how to go about this? GH file attached.
Excellent question. I’m aware of this occupant behavior model and I have through a lot about how to use it in Honeybee.
I think that this EnergyPlus object is actually made to simulate occupant window control using models like this but it requires an entire airflow network to use. At the moment, HB does not have the airflow network implemented but, as soon as OpenStudio finishes adding it to the SDK (which should be soon according to the activity that I have seen on the NREL github), I will implement it in Honeybee and you can hopefully use this object.
For the time being, I have this (somewhat hacky) workaround. Instead of using a perfectly smooth curve, you break it up into a step function and use multiple “Set EP Airflow” components in tandem like so:
The graph actually describes the probability (from 0 to 1) of a window being opened, without making a distinction of opening fraction; it’s either fully opened or fully closed. There are other studies that have analysed the fractions but I haven’t gone there yet.
My problem is more concerning the ability to change Honeybee parameters mid-simulation. After each simulated hour, I’d like to use the operative temperature to determine whether the window is opened for the next time step. But it seems to be the case that E+ runs the simulation for at least a day at a time and doesn’t ‘remember’ the history of dynamically opening and closing windows throughout the day. To get the current operative temperature, I have to select the correct item from the 24h output of the simulation, where all preceding hours were simulated with either all closed or all open windows, except if a schedule was determined…
Come to think about, maybe the answer is to keep updating a schedule, however this seems really hacky, also the simulation probably takes much longer than it should because everything is initialised again and again (and I believe E+ calculates a warm-up phase prior to each simulation?).
However,
Langevin, Wen, & Gurian. (2015). Simulating the human-building interaction: Development and validation of an agent-based model of office occupant behaviors. Building and Environment, 88, 27-45.
uses EnergyPlus to model occupant behaviour dynamically. They say:
This exchange has been implemented in a Human And Building Interaction Toolkit (HABIT) that couples the full ABM in MATLAB with EnergyPlus via the Building Controls Virtual Test Bed (BCVTB)."
I have started using HB just recently, but I may be able to help on occupant behaviour modelling part. Here my comments on the problem:
As Chris already said operating windows in EnergyPlus is possible via AFN. Until they implement it in HB, I would say, in case of simple models, you can do it via IDF editor or text editor, if you get the concept. But if you assume that a specific ventilation happens if the windows are open, then you can only activate a ventilation object to represent window operation. But if the focus of the work is on window operation, I would not recommend the latter.
If you have an occupant behaviour model (OBM) which inputs an indoor environment parameter, there is a feedback loop, as the model output influences the model input. In such a case you need a run-time data exchange between the OBM and BEM. That is why tools like BCVTB or OB-FMU are used. But my recommendation would be to use EnergyPlus runtime language (Erl) as it conducts the run-time data exchange within EP (and you just need to run the EP model), but also because you are running EP via HB. I am not that good in HB, but I assume it would be easier that you implement OBM’s with Erl using IDF editor, and then add the string to your HB model.
I do not not know how familiar you are with EP input syntax, but I extracted the most relevant objects (for AFN and Erl) from one of my projects with a simple window operation model. The EP model is not running as it only includes relevant parts of a huge model, but I think it will help you. The idea of Erl implementation is simple: You read the indoor temperature, occupancy state, and previous state of a window with sensor objects, you give these to your program (which includes the logistic regression window operation model and determines the window states based on the estimated probabilities), and the program outputs the next state of the window via an actuator object.
Of course there are some details in the EP implementation, and you should read EP documentation about AFN and Erl. But if you follow this idea, I guess I can later help you with more detailed questions.
I’m trying to understand what you want to model here: are you trying to study the diversity of thermal preferences that might drive one person to want their window open at a given temperature and another not to (as in, evaluating this model of occupant behavior to test its plausibility)? Or are you trying to evaluate a building design with the assumption that, if occupants behave generally like they do in this behavior model, will my design have resulting interior conditions that people generally find comfortable (as in, plugging results into the adaptive thermal comfort model to understand if my design is good)?
If you are doing the latter, I would say that trying to use the model as a probability function can give you results that are potentially far from reality unless you know a lot of details about your occupants. If we ask what the difference is over a whole building of having all windows open to the given fraction or having a fraction of fully open windows dictated by the probability function, we have the same amount of open operable window area for both situations at any given time. The only difference is the interzone airflow depending on the arrangement of which windows happen to be open at a given hour. So, unless you know which room will have people who prefer warmer or cooler temperatures than other rooms, I don’t think that you will gain much by modeling this as a probability over a fractional area of window. In fact, trying to guess which rooms have the people that prefer warmer or cooler temperatures might lead you to get results that are more inaccurate than if you simply assumed all windows were open to a given fraction.
If you are trying to do the former (evaluate the plausibility of the behavior model), you can use the methods that @farhang.tahmasebi posted, most all of which are using the EnergyPlus Energy Management System (EMS) under the hood. While I haven’t used the EMS or Erl myself, I know of several people who have done so successfully to model things like special controls for switchable glazing based on the building properties at a given timestep of the simulation.
Thanks so much for your input! All this is part of a quest to find ways in which to model user experience in architectural design. I’ve been doing a literature review on various behavioural models and performance metrics to evaluate design options from a user-centric approach. So far, apart from crowd flow models, these human-building interaction models seemed to show some of the the more promising and concrete results. In anticipation of higher future availability of occupant data (IOT devices, smart homes etc.), I’m wondering if one could make the case for using such data to provide designers with more insights on likely occupant behaviour (or range thereof) and how to design spaces to promote certain behaviours.
As a first step, I was planning to experiment with some of the models and develop a better understanding of how occupants may interact with the building, how this could affect comfort and energy savings and how it may be affected by design decisions. I’m still unfamiliar with this and may be overestimating the benefit that this could bring - happy to hear your thoughts on this!
Thanks Farhang for sharing the model. I haven’t used EnergyPlus without HB nor have I used Erl but sounds worth checking out. I’ll share some results as soon as I have any and maybe I can get your feedback. What have you been using this for, i.e. what output did you produce? Was it a way of making the energy model more realistic or was there another motif?
Thanks for offering your help a while back - at last I’ve had some time to test your model. I’ve tried to run a simple simulation and add your code as “additionalStrings” to the E+ component in HB. I assume you are familiar with GhPython? If not, if you double-click the little component with the “v” and “a”, a text editor will pop up where I pasted your code for convenience, so that I can use custom window vertices. Apart from that, I just changed the zone name and added a window construction. Below are the error messages I’m still getting:
@MaxMarschall, the previous problem was due to the fact that there have been references to window frame and shading control objects that do not exist in the model part that I have shared with you. Sorry for this.
But the new problem is about a schedule that do exist in the model, and actually it is a critical object in your study, as the Erl programs overwrite this schedule to set window states.
Can you please share the IDF file that your Honeybee definition puts together and run?
Then you will get probably an error (depending on EP version) referring to an AFN field. Do this replacement in my original IDF file:
“1, !- Type of Rectangular Large Vertical Opening (LVO)”
to be replaced with:
“NonPivoted, !- Type of Rectangular Large Vertical Opening (LVO)”
Window objects refer to wrong surface names.
Then you will get errors on the surfaces that are not planer. I did not have time to dig deep as to how you did this mistake. Apparently you rewrite the coordinates in your code. But, I would recommend that you let Honeybee generates the surfaces and fenestration for you. The additional string for AFN and OBM does not need to include the window geometry objects with coordinates, but you should only update my original non-geometrical IDF objects, such that they refer to the zones, surfaces and windows with the right names generated by Honeybee.
Added. What is this for? My guess is that it sets default schedules for electricity/occupancy etc., but I thought that the zonePrograms_ input of the Masses2Zones component in HB already does this? I’ve noticed that the idf has heaps of ScheduleTypeLimits objects - what is that about?
Done
/ 4. The non-convex error went away simply by restarting Rhino (I think it may have been an issue due to switching back and forth between unit settings). I’ve determined the room dimensions parametrically now and used the glazingCreator to generate the windows. It looks like the simulation ran fine except for some minor warnings.
How do I now find out when the window was actually opened? None of the inputs from the EPOutput component seem to allow you to do this.
In the model CON2 is the schedule used for window states (as we had multiple contact sensors measuring window states and we named the second one CON2!!!).
Window states are defined in EnergyPlus as venting availability in the AirflowNetwork:MultiZone:Surface objects (1 meaning window open, 0 meaning window closed).
The idea behind the CON2 schedule is that we start the schedule as always zero, then the Erl program overwrites the values of this schedule at each interval (either 1 or again 0).
I see…so is there a spreadsheet of the final schedule somewhere, to find out after the simulation when the window was open? I’d like to plot the effects that the openings have on indoor climate.
Also, how would I go about incorporating outdoor temperature into the logit equation as some proposed models do? Would I have to set up another sensor?
@MaxMarschall, you can get the values of any schedule as output, using the EnergyPlus output variable “schedule value”.
As for the outdoor temperature, if you have such a model, yes, you should implement it like the indoor temperature, as follows:
A sensor reads the values, which is the string below:
EnergyManagementSystem:Sensor,
Tout,
Environment,
Site Outdoor Air Drybulb Temperature;
The new model coefficients should be defined in the separate program intended for them (Coeff_agg)
The new variable multiplied by its coefficient should be added to the linear function in the other program (Window_agg_con2).
So, you need to spend some time to understand and customise the code.
If you are looking for such a model (which has both Tin and Tout as explanatory variable), I can suggest you one or two. The model that I recently developed is based on an office in Vienna and the explanatory variables are Tin, Tout and their interaction (Tin*Tout) to also capture the situation in very hot summer days in Vienna, when the occupants are not willing anymore to open the windows. As this paper is not published yet, let me know if you want to have it.
How come the window states can have values other than 1 or 0? (I multiplied the values by 10 to zoom in to the graph)
Just for clarity in your code: Could the PrOAReset and randomSeed programs be condensed into one? Also, does the calling point “AfterNewEnvironmentWarmUpIsComplete” mean that they are run only once, at the beginning of the simulation? Why is Coeff_agg run every time step - isn’t this just setting the coefficients?
The algorithm I was referring to was Rijal, H., Tuohy, B., Humphreys, P., Nicol, M., & Samuel, A. (2011). An algorithm to represent occupant use of windows and fans including situation-specific motivations and constraints. Building Simulation, 4(2), 117-134.
It would be great to read your paper if you’re willing to share!
@MaxMarschall, I do not have time today to get back to my code for some of your questions.
But, as for the states, my only guess without seeing the model is that the states are set for sub-hourly time intervals (that’s the Erl concept, unless you change timestep to 1, which is not recommended), but you may working with hourly outputs.
The other thing that is worrying me in the figure is that I do not see that Tin reacts much to window state. I would recommend that you:
a) Check the resulting air change rates as output to see if the values make sense for open and closed states
b) Determine your strategy as to how you want to use the window operation model for two windows (does one random number determine the state of both, two random numbers, two models, dependencies in the states?). Note that, if you work with one window, you need to have cracks in another wall, so that the flow happens.
Remember that what you are doing is a very complicated task in energy simulation. So, the first thing is, of course, to make the model work. But more importantly, you must go through iteration after iteration until the AFN and OBM implementations make sense.
@MaxMarschall, apparently I looked at your results in such a haste, that I misinterpreted it. Actually the variations of operative temperature do correlate reasonably with your window states. So, my previous comment may not be very relevant, but checking the air change rates, and being clear in your methodology about dealing with two windows may still be helpful.
You’re right, the time step in the IDF is 6, which explains that the window state values are multiples of 1/6.
Re air change rates, what is the variable name I am looking for? I’ve found Zone Air Heat Balance System Air Transfer Rate [W] and Zone Infiltration Standard Density Volume Flow Rate [m3/s], both of which are 0…I don’t understand how this can be, when the window opening does have an effect on the temperature.
One thing I’ve noticed is that I copied all your AirflowNetwork:MultiZone objects but I only have 1 zone - is that a problem? At the moment I’m pretty sure that one random number determines the state of both windows since each window has its own AirflowNetwork:MultiZone:Surface object with the same settings.
By the way, I deleted these three lines of your code since lastDep_occ2 wasn’t declared anywhere. I suppose that this is about prevent night ventilation?
if lastDep_occ2==1, !- A26
set con2_current=0, !- A27
endif, !- A28
@MaxMarschall,
Output: Try AFN Zone Infiltration Air Change Rate [ach]
1 zone: No problem in principle, in my view
2 windows: Simultaneous operation of two windows would be hard to argue for. But depends on your research question.
code part: yes, to avoid the windows left open when the occupant leaves the office.
