Running Experiments

Important Caveats:

1. While Alfalfa enables simulations to be interacted with during runtime, it does not specifically coordinate co-simulation (i.e. ensuring models are time coordinated, that inputs/outputs are coordinated, etc.).
2. Alfalfa is designed to step through model time at 1-minute intervals for EnergyPlus models, however, the way that the simulation steps through real time varies and is discussed below. It is mainly designed to step through a model in three different ways.
3. Alfalfa uses a start and ending datetime to drive the simulation. For EnergyPlus, these get written into the IDF file before run. If none are specified, they will default to January 1st, 00:00:00 and December 31st, 23:59:00.
4. While a goal of Alfalfa is to convert model objects into Haystack entities, this does not get done for all things.

Guidance on Choosing a Simulation Engine

As of 3/2023, Alfalfa supports upload of fmu, or zip (a zipped-up version of the OpenStudio workflow directory structure) files.

Users coming to Alfalfa likely have different backgrounds - some will come from a purely controls world, others from an energy modeling world using OpenStudio/EnergyPlus, and maybe others from the Modelica world. There are distinct advantages and disadvantages to both from an Alfalfa perspective.

EnergyPlus

Using the E+ simulation engine has distinct advantages in terms of the tooling availabe to quickly and easily generate models, typical systems, etc. (namely, OpenStudio or Eppy). That said, in order to make controls work as expected in real-life, custom EMS code must currently be developed to enable controls to behave as expected (see Alfalfa Control).

Modelica

While the Modelica Buildings Library is currently being built up, there is significantly less tooling available. Most models will need to be generated by hand and significant understanding of the Modelica language is required for proficiency. That said, Modelica is significantly more robust in implementing controllability to an energy model that is in line with how real systems operate.

Stepping Through Simulations

Advance via an external call

1. In this scenario, the model will only advance when explicitly told to advance by an external call. It has no regard for real time passing but sits in an idle state until told to advance. The simulation starts at the specified start time.
2. Upon call to advance, Alfalfa will look for any points written from external sources, write these into the simulation, and advance the simulation one time step (1-minute in model time).
3. It then waits to advance until the next call is made.
4. It will stop if the model has advanced enough times such that the end datetime has passed or if it is specifically told to stop.

Advance at a specified timescale

1. In this scenario, the timescale parameter is used to control the rate at which the internal clock advances through the simulation. It represents the integer ratio of model_time:real_time. For example, a value of 5 means that the simulation will advance at 5x the rate of real time. In other words, one minute of simulation time will occur every 12 seconds of real time.
2. Regardless of the start time specified for the run, the simulation will begin running.
3. Upon reaching the time to advance, Alfalfa will look for any points from external sources, write these into the simulation, and advance the simulation one time step (1-minute in model time).
4. It then waits X time in real time before advancing through the next time step.
5. It will proceed until it has reached the specified end datetime or if it is specifically told to stop.
6. If the simulation falls more than 2 timesteps behind it will throw an error and kill the simulation.

Advance in real time

1. This scenario is similar to the timescale with the following caveats.
2. The timescale parameter is always one (i.e. the model advances one minute in model time for every one minute that passes in real time).
3. If the specified model start time has already passed in real time, the start time will be overwritten to the current time and the simulation will begin. However, if the specified model start time has not already passed in real time, the simulation will not begin until that time in real time is reached.
4. It will then proceed until it has reached the specified end datetime or if it is specifically told to stop.
5. All external calls to advance the simulation are ignored.

Alfalfa Control

One of the more important aspects to understand about Alfalfa is that the actual control implementation is completely dependent on the underlying simulation engine used. While time delays, PID loops, etc. can be exposed if running a simulation with a Modelica model, these do not exist in EnergyPlus. As EnergyPlus’ default run logic is to meet loads at all times within capacity constraints, this is not necessarily how control would be implemented in the real world and generally deviates from expectations, especially for those familiar with real world controls and limited background with simulation tools. This isn’t to say that writing to a point exposed by Alfalfa can’t have the desired effect in simulation, rather, EnergyPlus experience is needed to:

1. Understand the underlying simulation calculation and run order
2. Design Energy Management System (EMS) logic that works behind the scenes of Alfalfa, such that writing to an exposed point has the intended effects.

Control Descriptions

Therefore, it is best practice to provide pseudocode or a narration document of expected equipment run logic such that strategies to implement this control using EMS and Erl can be discussed and appropriately developed. As part of generating the pseudocode, users should answer the following:

• Which equipment am I planning on controlling / interfacing with?
• What points am I expecting to be able to read from during the simulation?
• Which points am I expecting to write to during the simulation AND what is their desired effect on the simulation during run?
• At what point during the simulation should the write points be evaluated? Refer to the EMS Application Guide – Chapter 6 for information on EMS Calling Points.
• What other logic am I expecting out of the simulation engine after reading from / writing into?

At the end of this task, project teams should have developed a comprehensive equipment and points list, while also identifying whether those points will be read or write points. An example of this is shown below:

Designing Control Tests

To support this, the project team should develop a few (1-3) experiment specific tests, which should be highly aligned to the actual experiment. These tests could be as simple as the following:

1. Turn an RTU fan on/off. After actuating control point, the energy consumption is expected to increase/decrease and we expect to see air flow at the RTU discharge sensor.
2. Turn the heating/cooling stages to stage 1, then stage_2. After turning the heating on, we expect the discharge air temperature to increase and for the zone air temperature to increase over time. Similar for cooling. After defining the control tests, they can be implemented, the data historized, and then visualized using the Alfalfa python client (or any other client). This will help experimentalists test and verify their experiment design and modeling implementation.