Add Attributes and Schedules to People

[ed-p-may]

Hi @chriswmackey

I would like to ask it we can add some additional attributes to the Honeybee-Energy People object?

In order to comply with the new Phius REVIVE standard, they are asking us to set a few specific parameters to these objects for when we do OS simulations. Specifically they are asking for People in the simulations to be able to set:

• Carbon-Dioxide Generation Rate (default=3.82e-08)
• Thermal Comfort Model (default='Pierce')
• Clothing Insulation Schedule
• Air Velocity Schedule
• Work Efficiency Schedule

The intent behind adding these attributes is to enable the output of SET temperature (specifically, the "Zone Thermal Comfort Pierce Model Standard Effective Temperature" output variable) from the OSM simulaiton, which they use to verify winter-time thermal resiliency (to certify to their new program, we must show that the total SET degree-hours below 54°F are < 216hrs)

---

I'd be happy to put together a PR with this change if you would be ok with this addition? My initial thought is that these do not need to be exposed to the normal user or included in the normal Grasshopper object, and that they can be None in all 'normal' cases - but that they are available for us to add to internally for these new REVIVE calculations.

However If you think there is a better way of enabling these changes without modifying the HBE-People class I can certainly try another method? I originally began by sub-classing the HBE-People class and just adding these new attributes myself - but when the object is serialized/de-serialized as part of the to-osm workflow, all that subclass data gets lost since it just de-serialized as a normal HBE-People, so that didn't seem to work.

@ed-p-may

[chriswmackey]

Hey @ed-p-may ,

Sorry for such a late response here. I fully support exposing the Carbon-Dioxide Generation Rate, particularly because I am planning to add CO2 sensors in the near future. If you wanted to send a PR that exposes this, I can review it and add the corresponding PR for the honeybee-openstudio gem so that the feature is ready to be exposed in Grasshopper.

I was really hoping to avoid adding all of the People properties for PMV comfort because we have a whole other package that does this type of thing in a way that considers many more aspects of comfort than E+ can. It computes Pierce Model Standard Effective Temperature very well using this module.

I can easily give you a Grasshopper or Python script that computes this using ladybug-comfort:

enable the output of SET temperature (specifically, the "Zone Thermal Comfort Pierce Model Standard Effective Temperature" output variable) from the OSM simulaiton, which they use to verify winter-time thermal resiliency (to certify to their new program, we must show that the total SET degree-hours below 54°F are < 216hrs)

The script would work from the SQLlite file output by E+ as long as it has hourly (or sub-hourly) data for zone air temperature, MRT, and relative humidity (requestable through the comfort_metrics_ option on the HB Simulation Ouput component). Is there a chance that this could satisfy what you need for REVIVE or will they not accept the SET comfort values unless they appear somewhere in the E+ HTML output?

[ed-p-may]

Hi @chriswmackey ,

Right now I have created a custom Measure that can be used to modify the People objects, and I saw that you created something similar as an OSM 'patch' in the post from the LBT forum here. Both of those options can work for sure.

My thought about having these items exposed through the API was more about keeping things as simple for the users as possible - it felt like adding a 'Measure' was sort of whole new step for many users, as is adding components after the IDF run - so I had thought that should try and keep everything 'before' the simulation (I'm thinking here mainly in terms of the GH scripts) component, and that would be the more straightforward for most users.

But certainly if that causes issues to expose those properties in the People object, then workarounds like the Measure or post-processing the OSM can work ok. I don't think that the Phius folks care that much whether the SET temps are calculated by E+ itself, or in some post-processing step necessarily. I am not familiar with the methodology of calculating these though - but maybe it is just something we could do within our own post-processing pipeline (we do all sorts of graphing and reporting of the results already). That might work, and then we could avoid having more components to manage in the user GH scripts?

[chriswmackey]

Thanks, @ed-p-may ,

Let's start with the CO2 generation rate and then we can work on the PMV/SET comfort calculation.

If this is the goal:

keeping things as simple for the users as possible

Then I agree that people shouldn't be using a measure but this is also not a simple workflow:

• Asking people to set up all of these people properties for met/clo/work on each room
• Then having them request an additional custom output of SET from E+
• Then run an additional post-processing step on the SET result to see if it meets the standard

The simplest workflow that I can think of is we just ask people to request comfort metrics from their E+ simulation. Then, we have a single component that takes the SQLite file and tells you whether you pass the standard in each room or not. This component will have inputs for met/clo/work/air speed if the user wants to change them from a default. The component will do the SET calculation on the fly such that, if people realize their assumption for something like clothing is not right, they can quickly change it without re-running the whole E+ simulation. And it can output data collections of SET if people want to understand which hours are responsible for not passing the standard.

If the above sounds like it's exactly what you want, then I'm happy to draft the component for you. It's probably just 100-200 lines of code so it shouldn't be too difficult to tweak if you need to and you can distribute it with honeybee-grasshopper-ph (or another plugin of yours that's specific to REVIVE).

[ed-p-may]

@chriswmackey , I totally agree:

Asking people to set up all of these people properties for met/clo/work on each room
Then having them request an additional custom output of SET from E+
Then run an additional post-processing step on the SET result to see if it meets the standard

For our new workflow in Honeybee-REVIVE (what we're calling the new extension) we have created a few new components that take in the user's model/rooms and adjusts all the relevant settings for them automatically.

Just by way of some additional context, in case it is relevant: the intended workflow for Honeybee-REVIVE is currently:

1. The user creates a normal HB 'base' model which includes all the normal geometry and program, etc..
2. Using Honeybee-REVIVE, a first model is built from the base to do an annual simulation, and then a total life-cycle carbon-cost assessment using a method that Phius invented (I think?) called 'ADORB'
3. Using Honeybee-REVIVE's Grasshopper components, we the take that base and create two more 'Resiliency' models, one for summer power-outage, and one for winter power-outage. This is done using a GH component which goes in and modifies relevant settings (turns lights off...) and sets simulation variables (adds 'SET temp', sets up the power-outage time based on STAT files, etc..)

So we have built several GH Components to convert / set the relevant model parameters automatically for users in this scenario. So my thought with these new People attributes was that (for our use-case at least) these would not need to be user-settable or exposed attributes, or anything the user would interact with through GH or otherwise. But so long as they are accessible through the SDK, that is all we need for our intended use-case, since we can go in and set them all up based on the program rules.

If you are interested, we have a couple really simple example files here:

• ADORB
• Resiliency

which show the proposed workflow and components in a little more detail.

---

But yes, the workflow we have is pretty much exactly what you outlined, with the one difference that we are expecting the SET to come from the E+ SQL directly. But I do not think that it is at all an issue to calculate that in a GH component instead (we already have 'post-processing' components that do the graphing and summarizing after the sim is done - so it can easily just get added to those) - provided that the SET method is outlined / documented someplace? I am just not familiar with what that calc is and how it is done?