Question-and-Answer Resource for the Building Energy Modeling Community
Get s tarted with the Help page
Ask Your Question
4

Best Practices for Adding Occupant Loads to a Space in the OS API

asked 2016-06-09 17:40:54 -0500

Using OpenStudio's ruby API:

Suppose I have defined an activity level schedule, activitySchedule, and then created a PeopleDefinition object person and a People object: people = OpenStudio::Model::People.new(person) and assigned the activity schedule to people.

How do I add people to a space as a load?

Bonus question: Is it more appropriate to create a single PeopleDefinition object with the number of people set to 1 and share it with each space that has the same occupancy, adjusting the number of people with the space's setNumberOfPeople method

OR

Should I create unique PeopleDefinition objects for every single space?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2016-06-10 11:02:39 -0500

updated 2016-06-10 11:06:23 -0500

People objects can be assigned to a SpaceType or to a Space. The code below shows you how to add it to a space.

# add a new space to the model
new_space = OpenStudio::Model::Space.new(model)
# create people def and instance (def can be shared across instances)
people_def = OpenStudio::Model::PeopleDefinition.new(model)
people_inst = OpenStudio::Model::People.new(people_def)
# assign instance to space
people_inst.setSpace(new_space)

To answer your second question, take a scenario where you have 6 conference rooms across a facade that are all the same size, except for the corners which are slightly larger, but will seat the same number of people. Below are some options.

  • You can just create a single definition that is set as occupancy per area. Then you can assign this to all the spaces individually or to a "Conference Room" space type if you have one. Sure, the corner ones may say they have 20.3 people vs. 20.0 but for most modelers that won't matter, after all sometimes an extra charge may be brought in.
  • You could still use a single definition but set it to 20 people vs. an occupancy per area value. Then you can assign it to all 6 conference rooms and they would all show exactly 20 people. The downside of this approach is if you have multiple sizes of conference rooms you need a unique definition for each. With the occupancy per area approach one definition may work for all conference rooms, regardless of size.
  • A third approach, which you describe is to create a definition that is just set to be a single person. Then when you assign this to spaces you would change the instance multiplier to the actual number of people. This would let you only have one definition but you would have to change the multiplier on all space or space types that use this.

I think the first option is most typical, and probably about as far as most modelers go, at least for people. But it wouldn't be uncommon to have a definition be a specific fixture or computer where the instance multiplier is used indicate how many exist. As long as it models the conditions you want, any of them are fine. In all of these cases, if you want to customize the activity level it has to be done in the instance.

There is one case where I see benefit in having multiple people instances within a space. In a building like a restaurant I could see the benefit of having definitions for kitchen staff, dinning room staff, and diners, each with unique definition occupancy values. You would then make instances that have different schedules and different activity levels. This would allow you to easily change the schedules independently from each other. If you use a single people instance to represent different groups that occupy a space it can be hard later to infer where the makeup of the schedule came from. This is ... (more)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

 

Question Tools

3 followers

Stats

Asked: 2016-06-09 17:40:54 -0500

Seen: 474 times

Last updated: Jun 10 '16