EnergyPlus incorrectly dismisses schedule values if set outside of zone time step

[mwetter]

The model Buildings.ThermalZones.EnergyPlus.Validation.NonalignedSchedule tests the following:

Model that validates that schedule values need not be aligned with the EnergyPlus time step. In this situation, if it represents a continuous-valued schedule (such as for an internal gain), EnergyPlus should time-average the schedule values over the EnergyPlus time step. If it represents an instantaneous value such as a control state, then EnergyPlus should use the instantaneuous value at the start of the EnergyPlus time step. This validation tests a continuous-valued schedule.

Both buildings are identical, but in one building, the schedule that determines the internal heat gains switches on and off every 10 minutes, while in the other one the schedule is on from 3 minutes and off after 8 minutes, but the schedule values is twice as large in order to add the same amount of internal heat to the zone over an EnergyPlus time step. Because EnergyPlus uses a fixed time step, both models must result in the same air temperature.

The input to EnergyPlus which uses 6 time steps per hour is as follows:

This input is sampled every 60 seconds.

EnergyPlus computes the following room air temperatures:

Hence EnergyPlus seems to ignore the schedule value.

[mwetter]

The example is on branch issue2000_spawnScheduleNonaligned which is based on issue1633_schedulesActuators.

@kbenne : Please see this test case. It looks like E+ ignores the setReal commands in between zone timesteps, which gives a wrong result in this test.

[mwetter]

For release, either fix it, or update the info section in Buildings.ThermalZones.EnergyPlus.Schedule and review the users' guide to make sure the documentation is correct (currently it mentions sampling).

[mwetter]

Won't be fixed immediately, todo:

• [x] Update documentation.

[mwetter]

Commit https://github.com/lbl-srg/modelica-buildings/commit/3d3bab54d4daecba1ea6359a8db6cfee2575b164 is on branch issue1633_schedulesActuators as this is the development head for the actuators and schedules.

[mwetter]

mwetter to check if this is fixed on the release, it should be fixed in the Spawn binaries

[mwetter]

@kbenne : This is not fixed with the latest E+ binaries, i.e.,

$ grep commit Resources/src/ThermalZones/EnergyPlus/install.py
    # The setup below lead to a specific commit being pulled.
    commit = "3ec0a1fa6e31452fcb5b9318ea85c5610995e50b"
    name_version = f"Spawn-0.1.0-{commit[0:10]}"

I tested it with b9b498e11d on branch b9b498e11deeb4ce8b45928466cf1b4d92ff9e40 and model as above. The output below is from this model, just for different time windows. The expected behavior is that both models have the same zone temperature.

[kbenne]

There is a test https://github.com/NREL/Spawn/blob/release/0.1.0/test/test_single_family_house_lights_control.cpp#L14 which confirms that when you actuate a schedule, the corresponding output (a lighting load in the test) is updated immediately. However, there is a fair bit more going on in the example you have outlined here. I'm going to have to think about it a bit more, but I think generally the title of this issue is not the root thing causing the results we see in the graphs.

[mwetter]

It appears that the heat balance in EnergyPlus does not see the average heat input over the time step, but rather it sees an instantaneous value and therefore the intermediate settings do not appear in the energy balance.

[mwetter]

This needs more design, what happens to connected and unconnected zones, and what happens to walls if the E+ time step is large compared to the signal it gets.

Compare also BCVTB interface with averaging/instantaneous signal.

[kbenne]

Hi @mwetter ,

I'm hoping to revive this discussion and I added a few more tests to help illustrate. You do not need to setTime on the EnergyPlus FMU at intervals corresponding to the EnergyPlus timestep. In fact, currently, if you change a schedule associated with a zone load you will instantaneously see the impact on the zone's senible heat gain. A possible way forward is to use this fact and advance time and integrate the heat balance at time intervals correlated with your desired (schedule) input resolution rather than the EnergyPlus timestep.

See the new test in this commit.

[mwetter]

@kbenne : Advancing time and integrating the heat balance to the point set with setTime seems to right thing to do. Per the FMI standard, calling setTime is needed, see also https://lbl-srg.github.io/soep/softwareArchitecture.html#time-synchronization. In summary, the following should work: Suppose the EnergyPlus time step is 10 min, model time is t=0 and the schedule (or actuator) is called u . If setTime=2 is called, integrate up to t=2 with the current value of u. If fmi2SetReal = 1 is called to set u(t=2) = 1, update the schedule value by setting u=1. When fmi2SetTime=3 is called, integrate from t=2 to t=3 with u=1. When fmi2SetTime=10 is called, integrate from t=3 to t=10 with u=1.

[kbenne]

In our most recent project meeting we discussed that the wall temperatures will still only update at the frequency of the EnergyPlus time step. I feel like this is acceptable, but I also recommend that I make a change that will enforce a one minute EnergyPlus time step for all Spawn simulations.

[mwetter]

@kbenne : I assume you mean the time step of EnergyPlus and not the synchronization time step. A 1 minute synchronization time step would computationally be too costly (due to many events being generated).

Even if this is only the EnergyPlus internal time step, I wonder

• What is the penalty on computing time for this measure?
• Isn't there an issue with CTF transfer functions for certain constructions if the time step is small? I remember some discussion many years ago (maybe 10-20 years?) that indicated that small time steps led to rounding errors in the time series calculations and subsequently large errors. I don't recall if this is an intrinsic problem (DOE-2 and TRNSYS had similar issues many years ago) or if it is fixed.

Wouldn't it be better to check when the input is changed, and then advance time to that point (within a minute resolution if that is a constraint in EnergyPlus)?

[mwetter]

@kbenne to look into it.