ASHRAE lighting schedules

[savage]

I was trying to figure out why my MidriseApartment::Apartment energy model had a substantially lower lighting EUI than equipment EUI despite both having a similar baseline energy density, and I found the lighting schedules to have very low fractions, like seen in the image (GH script attached). In this case, the maximum lighting fraction is only 0.18, and both summer and winter design days use the same curve. Is this a bug in the default schedules or am I missing something here?

Poking around the schedule.json file under the default honeybee_energy_standards directory, I see some lighting schedules have more reasonable values that peak at fractions close to one, and others that also seem off. For instance, the “Hospital BLDG_LIGHT_SCH_Default” schedule peaks at 0.1.

LB_LightingSchedule.gh (22.2 KB)

[AbrahamYezioro]

You don’t mention the schedule of the light itself (when it is on/off). Residential use is supposed to have low consumption (as compared to offices, for instance).
-A.

[savage]

Abraham, that schedule is supposed to be the fraction of the lighting on over the course of a day, not the lighting power; this schedule gets multiplied by the lighting power density to get the actual lighting loads.

You are right that residential tends to be lower usage than offices, on average, but it has high usage at some times of day, particularly in the early evening, so the fraction of lighting on should get close to one at times. There is an ASHRAE loads and schedules document here that gives much higher schedule fractions for multi-family, even 1.0 for a few hours in the evening, but I do not know if that document is current or not.

[AbrahamYezioro]

It may be that the schedule defined in the Mid rise apartment is faulty …?
You can see here that at no time you get the full fraction load. At the most you get 0.18.

It doesn’t fit the ASHRAE requirements, as they are:

Of course you can always define your own schedule.
-A.

[chris]

The schedules in the program types that ship with Ladybug Tools come from the DOE Commercial Reference Buildings, which are more focused on representing the US building stock than they are with following the most recent version of ASHRAE 90.1 to the letter. So, if you’re trying to follow ASHRAE perfectly, making your own schedules is likely the recommended workflow as @AbrahamYezioro states.

I would expect most lights in a residence to be off at peak if only because people tend to turn off the lights when they leave a room and, even at peak lighting consumption, spaces like bedrooms and closets aren’t likely to be occupied. But I agree that 0.18 seems particularly low and there may be a lot of bias from US residences here, which tend to have a particularly low occupant density compared to other countries.

[savage]

Thanks for the clarification, Chris. I pulled out several midrise apartment IDF files from the DOE Commercial Reference Buildings set (pre-1980, post-1980, and new construction for Phoenix), but am finding in all cases a lighting schedule that does not match what is in the LB database. The DOE models have lighting fractions a lot higher, reaching 1.0 in the evening.

DOE Midrise Apartment Lighting Schedule

  Schedule:Compact,
    APT_LIGHT_SCH,           !- Name
    Fraction,                !- Schedule Type Limits Name
    Through: 12/31,          !- Field 1
    For: AllDays,            !- Field 2
    Until: 04:00,0.067,      !- Field 3
    Until: 05:00,0.187,      !- Field 5
    Until: 06:00,0.394,      !- Field 7
    Until: 07:00,0.440,      !- Field 9
    Until: 08:00,0.393,      !- Field 11
    Until: 09:00,0.172,      !- Field 13
    Until: 15:00,0.119,      !- Field 15
    Until: 16:00,0.206,      !- Field 17
    Until: 17:00,0.439,      !- Field 19
    Until: 18:00,0.616,      !- Field 21
    Until: 19:00,0.829,      !- Field 23
    Until: 20:00,0.986,      !- Field 25
    Until: 21:00,1.0,        !- Field 27
    Until: 22:00,0.692,      !- Field 29
    Until: 23:00,0.384,      !- Field 31
    Until: 24:00,0.160;      !- Field 33

HB Midrise Apartment Lighting Schedule (also Highrise)

  "ApartmentMidRise LTG_APT_SCH": {
    "type": "ScheduleRulesetAbridged",
    "identifier": "ApartmentMidRise LTG_APT_SCH",
    "day_schedules": [{
        "type": "ScheduleDay",
        "identifier": "ApartmentMidRise LTG_APT_SCH_Default",
        "values": [0.011316031, 0.033948092, 0.0735542, 0.079212215, 0.0735542, 0.033948092, 0.022632061, 0.039606108, 0.079212215, 0.113160307, 0.152766415, 0.181056492, 0.124476338, 0.067896184, 0.028290077],
        "times": [[0, 0], [4, 0], [5, 0], [6, 0], [7, 0], [8, 0], [9, 0], [15, 0], [16, 0], [17, 0], [18, 0], [19, 0], [21, 0], [22, 0], [23, 0]],
        "interpolate": false
      },
      {
        "type": "ScheduleDay",
        "identifier": "ApartmentMidRise LTG_APT_SCH_SmrDsn",
        "values": [0.011316031, 0.033948092, 0.0735542, 0.079212215, 0.0735542, 0.033948092, 0.022632061, 0.039606108, 0.079212215, 0.113160307, 0.152766415, 0.181056492, 0.124476338, 0.067896184, 0.028290077],
        "times": [[0, 0], [4, 0], [5, 0], [6, 0], [7, 0], [8, 0], [9, 0], [15, 0], [16, 0], [17, 0], [18, 0], [19, 0], [21, 0], [22, 0], [23, 0]],
        "interpolate": false
      },
      {
        "type": "ScheduleDay",
        "identifier": "ApartmentMidRise LTG_APT_SCH_WntrDsn",
        "values": [0.011316031, 0.033948092, 0.0735542, 0.079212215, 0.0735542, 0.033948092, 0.022632061, 0.039606108, 0.079212215, 0.113160307, 0.152766415, 0.181056492, 0.124476338, 0.067896184, 0.028290077],
        "times": [[0, 0], [4, 0], [5, 0], [6, 0], [7, 0], [8, 0], [9, 0], [15, 0], [16, 0], [17, 0], [18, 0], [19, 0], [21, 0], [22, 0], [23, 0]],
        "interpolate": false
      }],
    "default_day_schedule": "ApartmentMidRise LTG_APT_SCH_Default",
    "summer_designday_schedule": "ApartmentMidRise LTG_APT_SCH_SmrDsn",
    "winter_designday_schedule": "ApartmentMidRise LTG_APT_SCH_WntrDsn"
  },

The hospital schedule if fine – the one I referenced is not used for regular days (my mistake).

[chris]

Thanks, @savage ,

The values that we have pretty clearly matches what the OpenStudio Standards gem says that it is pulling “From DOE Prototype Buildings” in this file on their GitHub:

Where did you get that IDF of the prototype building? Is it for an ASHRAE 2019 version of the Midrise Apartment and does the value for the LPD in the IDF also match with what we have in the Midrise Apartment LBT Program?

If it does, then there may be an issue with how OpenStudio Standards is pulling the schedule from the prototype building. If the LPD for your IDF of a 2019 version Commercial Reference Building is lower than what the program is in the LBT Midrise Apartment template, then it’s possible that the Standard Gem is just accounting for this change in LPD through the schedule (perhaps so they can use the same schedule for different versions of SAHRAE 90.1).

[savage]

That is definitely strange – I see from the NREL github history the lower lighting fractions have been present there since the first commit of that file in 2019.

The schedule I posted above can be found in the prototype building models from the link you shared above; for example, grab one of the zip files from here.

However, it appears the prototype models are now being maintained on this energycodes.gov site. On this site, I find the very low lighting schedules for midrise apartments in the IDF files for all ASHRAE years available: 2004 to 2019 (also in the one IECC file I checked). There are two issues I find with the change here that leads me to believe the new schedules are incorrect:

• Both the energy.gov and energycodes.gov sites (both DOE sites) have models for 2004, but the schedules differ.
• The energycodes.gov site also has reference models for single-family and lowrise apartment buildings, which (even for IECC 2021) have higher lighting schedules, very similar to the original schedules. In other words, the prototype models suggest single family and lowrise residential occupants use their lights 5.5 times as often as midrise and highrise residents and that, even during design days, residents in the latter case never have on more than 18% of their lighting.

Is there someone at NREL or PNNL we should be asking about this?

[chris]

Hey @savage ,

The recommended way to get the most recent version of the prototype building is to use the Create DOE Prototype Building measure. This will give you a version of the prototype building that is intended for the latest version of EnergyPlus and OpenStudio without loss of information. It’s possible that the models at energycodes.gov are generated from the measure but here is an OSM of the Midrise Apartment 2019 model, which works with OpenStudio 3.6:

MidriseApartment2019.osm

I can see that the OSM has the schedule we are currently using in Ladybug Tools and that we pulled from the OpenStudio Standards gem:

If you want to ask NREL about this, the right place to do it is probably the Unmethours forum since that’s were many of the OpenStudio developers answer questions. You’d probably want to get some feedback from Matt Dalhausen who maintains the standards gem. If you’re convinced it’s a bug in the standards gem, you could also try opening an issue on the OpenStudio Standards GitHub.

[savage]

I opened an openstudio-standards issue here.

Poking around the files on that github project, they reference the ASHRAE schedules as being pulled from the 2004 DOE prototype models, but I do not see any description as to why that is not the case for apartment lighting schedules.

[mdahlhausen]

The apartment lighting schedules in openstudio-standards match the recent DOE/PNNL prototype model for apartments (see Chris’s link above):

ApartmentMidRise LTG_APT_SCH Default
0.011316031
0.011316031
0.011316031
0.011316031
0.033948092
0.0735542
0.079212215
0.0735542
0.033948092
0.033948092
0.033948092
0.033948092
0.033948092
0.033948092
0.022632061
0.039606108
0.079212215
0.113160307
0.152766415
0.152766415
0.181056492
0.124476338
0.067896184
0.028290077

That said, I don’t think those schedules are very accurate. Here are the baseline schedules used in ResStock / OpenStudio-HPXML, which I think is more accurate at modeling residential units:

NREL/resstock/blob/develop/resources/hpxml-measures/tasks.rb#L2101-L2109

[savage]

Hey @chris,

It looks like the low schedule fraction models have much higher LPDs that make up for it. However, it looks like the changes in how the prototype models deal with lighting also involved a separation of the LPD into separate contributions from fixed and plugged-in lighting fixtures, but Honeybee (and ClimateStudio as well) is only using the fixed fixtures LPD, not the total LPD (about 50% larger). Is this a Honeybee issue or upstream issue?

[chris]

Thanks for the explanation @mdahlhausen . Good to have confirmation that there weren’t any issues on the OpenStudio Standards end. It’s also nice to have your recommendation with the HPXML schedules.

To answer your question @savage , I can see that the latest version of the Midrise Apartment reference building has two separate lighting definitions, which I assume refer to fixed vs. plugged-in lights that you mention:

We’re not currently capturing the extra lights in the MidriseApartment::Apartment Program that we expose in Honeybee since we only work from the lighting_per_area. However, I see that the data for the additional_lighting_per_area is in the data of the standards gem here:

NREL/openstudio-standards/blob/master/lib/openstudio-standards/standards/ashrae_90_1/ashrae_90_1_2019/data/ashrae_90_1_2019.spc_typ.json#L8332

… and they both use the same schedule in the reference building OSM. I can update our routines that work from this data to ensure that we sum both the lighting_per_area and the additional_lighting_per_area when we translate it to the Honeybee format. This would mean that the program would get a total LPD of 0.87 W/ft2 or 9.3646 W/m2. This would close the ~50% gap that you currently referenced.

Does this sound good to you?

[chris]

I have put together the PR to update the Honeybee Program Types with the additional lighting here:

fix(programtype): Ensure program type accounts for additional lighting

… and I will merge it shortly. It seems that the only programs that were affected were the following:

• HighriseApartment::Apartment
• MidriseApartment::Apartment
• StripMall::Type 1
• StripMall::Type 2
• SuperMarket::Bakery
• 2019::SuperMarket::Deli

Interesting to see how this additional lighting was used. I guess the strip mall lighting was for illuminating the merchandise and the supermarket lighting for illuminating the food.

FYI, @mdahlhausen , I noticed that all of the space type info for the College Building type seems to be complete and so I have also exposed that in Honeybee. Congrats on getting that one implemented.

[savage]

Sounds good, Chris – thanks for the quick update!