Revision history [back]

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 for lighting or 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. This is also true for modeling lights or electric equipment as a single LPD or EPD value. This is beyond what would be useful in early design but could be beneficial when looking at operational changes or EE measures as the design develops.

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 for lighting or 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. This is also true for modeling lights or electric equipment as a single LPD or EPD value. This is beyond what would be useful in early design but could be beneficial when looking at operational changes or EE measures as the design develops.

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. came from. This is also true for modeling lights or electric equipment as a single LPD or EPD value. This is beyond what would be useful in early design but could be beneficial when looking at operational changes or EE measures as the design develops.