Consider using AlwaysOn schedule for Ventilation when unspecified

[ed-p-may]

Hi all,

I would like to raise a small issue I've been running into a lot lately regarding room.properties.energy.____

I would like to propose eliminating the None state for all properties.energy Load fields such as people, lighting etc...

In practice, I find that when working with program objects and Loads, I am doing a lot of checking for None each time I touch them, since all Loads might (and often are) None, and within Loads all Schedules might also be None as well. ie:

if hb_room.properties.energy.people:
    # proceed with the operations ....

if hb_room.properties.energy.ventilation:
    if hb_room.properties.energy.ventilation.schedule:
        # proceed with the operations ....

I also think it is unclear what it 'means' when we get a None in some of these cases. For instance, when hb_room.properties.energy.ventilation.schedule is None, I think that means constant fan-speed / operation (right?). But I'm not sure what it 'means' when the people is None, or the people.schedule is None? That doesn't seem quite right to me, and I would think that having things more explicit would make more sense and be clearer.

So I wonder if it would be better to have all 'Loads' have a default set to 0 for all loads, and schedules set to Constant 0? That way we can avoid having to constantly check if ...properties.energy.people: when operating on these rooms and it is explicit when these loads are not yet set by a specific program type.

But: is there some other reason that you might want these set to None in some cases? I haven't found any, but not sure if someplace that is an important flag for some reason? Again though, given that's unclear how to handle None cases when they occur, its not clear that None is a desirable state for any of the Load objects, and that some sort of standardized / explicit handler would be better in each case.

-Ed (@PH-Tools)

[chriswmackey]

Hey @PH-Tools ,
Sorry that I realized I forgot to respond to this a while back. I didn't see it since it was originally posted under honeybee-core instead of honeybee-energy. Generally speaking, everything related to energy simulation should be posted here instead of the core.

I sense that a few of the cases being discussed here aren't ones that can be created with the Python libraries. You'll never have a case where people.schedule is None since People cannot be initialized without a schedule. Also, I'm not sure that I follow the argument that it's ambiguous what a load of None signifies since I'm not sure what else it would mean other than "no people in the room", "no hot water usage", "no ventilation requirements", "no thermostat setpoints", etc.

But I can definitely understand that there are some cases where you don't want to first check if a load is None before you get a value. I would be more than happy to add some attributes to RoomEnergyProperties that always return a number for a given load value. So I could add a equipment_watts_per_area that can return a value of 0 if there's no equipment assigned to a room. I could do this for all loads except the thermostat setpoints.

I'm would be a little less happy to implement a property that creates a whole dummy load object when there's None assigned to a Room because this would require a whole dummy schedule for most load objects (I guess it would have to be an "Always Off" schedule or something like that).

What do you think?

[ed-p-may]

Hey @chriswmackey
No worries, apologies for mis-posting. I'll make sure to post here in the future.

But good point: I guess you are right that you can't have a 'people' without a schedule, can you? But you can have a Ventilation without a schedule I think? And you can have People itself be None as well, right? And I think the People.schedule can have 0-rules on it?

I guess this was mostly around the Ventilation schedule part though more than People? When the schedule is None does that mean 0% flow, or 100% flow? I think constant 100% flow, yes? That was part of what I was a little confused about. IMO I would think having that default to 'Always On' would be more clear in that case (if that's what None means in that case? Not sure i have that right though?)

I was just thinking that it would be easier / more consistent for there to always be loads and schedules in all cases (so never any Nones), and if the value is 0 then that's fine, but then you would avoid all the checking against the properties before doing further operations and it would be super explicit what was what. But yeah if that adds a ton of dummy classes and makes things messier, then its not a big deal to check for None first.

But tbh, this was mainly related to Issue#838 where I was just getting confused with things before realizing that I needed to test for None (if ventilation.schedule is None:) explicitly instead of using the if ventilation.schedule: construct. Once I sorted that part out, I was able to resolve the issues I was having.

@PH-Tools

[chriswmackey]

Hey @PH-Tools ,

Thanks for the clarification. I think that using AlwaysOn when the schedule is unspecified is something that makes sense and we can support in the Python libraries. I think I'd still like to keep is as None/missing when we export it to HBJSON, OSM, and IDF. But I can make the Ventilation.schedule property always return a schedule object.

I'll try to address this along with this other issue concerning Ventilation at some point in the near future.

[ed-p-may]

That's great - I think that will make things a lot easier.