Temperature Capacitance Multiplier default values

[jmaguire1]

A little background for everyone:

EnergyPlus has a "temperature capacitance multipler" (TCM) input that affects the thermal mass of the building. While we explicitly model massive objects like furniture and interior walls, the temperature capacitance multiplier applies directly to the air node in the space and increases it's capacitance by the TCM. We've noticed if you simulate quick temperature changes, either due to setup/setback or starting an outage, the indoor temperature drops quicker than we'd expect with a TCM of 1.0, the default.

If you look at the literature, others have noticed this and in model validation come up with values ranging from 3.6-15. It's a pretty wide range which is implying that the mass is somewhat building specific. We also think that part of why you might need a TCM > 1 is that we're not explicitly accounting for the duct volume, which does have some impact on how quickly the thermostat sees heating/cooling reach the thermostat. It's hard with the data available to disentangle this impact from the potential of missing some thermal mass in the buildings.

We've been defaulting to a value of 7.0 in OCHRE . 7.0 is based on HIL experiments Bethany and Sugi performed with a lab home (simulated occupants, so basically everything was known) when they tried to calibrate the home model to the field data. It's also close to the middle of the range seen in the literature.

In cases with no outage/constant setpoints, I'd expect next to no impact (like 1-2 % difference in annual whole home energy). The impact will be a little bigger if there's setup/setback, but also still pretty small annually. We might underestimate how much load can be shifted if we're underestimating the thermal mass though. This matters quite a bit more if you have either an outage or the house temperature is floating (ie if it has no cooling in the summer). It seems like we have more global cooling measures and some projects are starting to look at modeling outages, so I want to raise the issue that we might want to change the default value so people don't have to worry about this in those use cases.

A couple questions I think we should discuss:
@shorowit: I know you and Yueyue did some investigation of this, but ultimately decided to keep the 1.0 value as the default. If I recall right, there were some validation tests that were just barely failing when we used a value > 1.0 in OS-HPXML. Am I recalling that right? I debated if we should move this issue to OS-HPXML rather than ResStock, but I think we still want to keep the 1.0 value to avoid failing some tests.
@afontani: At one point we did have a default > 1, but then we reverted it. If I recall right we saw a minimal impact on annual energy consumption and concluded it wasn't important enough. Is that about right? Use cases have changed since then in a way where to me it seems like we ought to at least talk about reconsidering.

[jmaguire1]

One more idea here... I was at the PLMA (peak load management alliance) conference and two utilities, Duke and PGE, presented on their smart thermostat DR programs in quite a bit of detail, including the specific day/time of events and the response. Perhaps useful for checking that when we do setup/setback we see the right response (which is very sensitive to thermal mass)?

[jmaguire1]

Tony, Scott, and I had a chat about this one. There's still quite a few unknowns as for what's actually causing us to need a TCM (could have to do with the volume of the ducts or our well mixed assumption). It sounds like Tony might have a project later this year that'd have an opportunity to do some more detailed digging here, so we'll put this on hold for now until that can happen this spring.