Changes to "InService" as of SAInt v3.9

Why this change was needed

This change was required to support “non-spinning” reserve provisions. The release of SAInt 3.9 comes with a new ancillary service type: NonSpinning. For a generator to provide this service, it must be offline (not generating) but available to turn on and generate power. This represents the ability of generators to quickly turn on and provide power should a contingency occur that warrants the need for back-up power.

The previous implementation of using ON, OFF, and ONOFF Events could not support this because there was no convenient way to know why any specific generator was online or offline. Rather than keep track of this behind the scenes and continue to report only the “STATE” output property specifying when generators were on or off, we opted to introduce dedicated properties to track the availability and commitment status of generators over time. We also extended this new behavior to all other object types for consistency. We believe this change will make SAInt more transparent and user-friendly.

In addition to supporting non-spinning reserves, this change comes with additional benefits:

  • Defining an outage profile for a generator (or any other object) is now very simple with one Event and one Profile.
  • Users can see explicitly what units are available and when, which can be helpful for debugging why power and/or reserve services are unmet when capacity is expected to be available.
  • For objects with a default InServiceDef property set to False at the Network level, this property can now be changed in a Scenario. Previously this was not possible – an ON or ONOFF Event did not have the ability to supersede InService equal to False.
  • The new Event Value Properties “InService” and “CommitStatus” can be queried using Value Expressions, so the operational characteristics of an object can be used directly as an Event Condition or to inform the Value of another Event such as the bounds of a custom constraint.

What changed?

Previously, the “InService” property for all non-container objects in SAInt was a Network property, meaning that this property could not be changed using an Event. Instead, there were ON and OFF events (and ONOFF events in the case of FGEN objects in DCUCOPF scenarios) available to change the operating status of an object in a scenario.

The ON, OFF, and ONOFF events have been removed as of SAInt v3.9. “InService” is now a Default Event Value property called “InServiceDef” and it can be changed for different scenarios using an InService event. The boolean nature of the “InService” property remains, however users also have the option of using integer values of “0” for “False” and “1” for “True”. This means that you can now attach a profile directly to an InService Event to control the operational behavior of an object over time, rather than using the previous method which required a PREF event with a profile and multiple “Conditional Events” referring to that PREF Event (described here).

Keen SAInt PCM users would then ask the following: What happened to the ONOFF Event? The operational behavior of unit commitment has been decoupled from the operational availability of objects. FGEN objects now have a new property called “CommitStatusDef”. This is an enumerative property with two possible values: “CYCLING” (0) and “MUSTRUN” (1). When an FGEN object has its CommitStatus property set to “MUSTRUN”, its operating state will match that of its “InService” property. In other words, whenever the object is available, it will be operating. When the CommitStatus property is set to the default value of “CYCLING”, the solver will determine its unit commitment status of the object when it is available according to the value of its InService proeprty. This property can also be changed using an Event, and a Profile can be used with the value of “0” corresponding with “CYCLING” and “1” corresponding with “MUSTRUN”.

What will happen if I open my SAInt model from v3.8 in v3.9?

When you open your SAInt model from a previous version in the latest version, the following conversions and default values will be applied automatically:

  • The InService property for all objects will be mapped to its InServiceDef property.
  • All FGEN objects will have CommitStatusDef=CYCLING
  • OFF events will be mapped to InService=False Events.
  • ON events will be mapped to InService=True Events.
    • A corresponding CommitStatus=MUSTRUN Event will be created for all ON events applied to FGEN objects in DCUCOPF scenarios.
  • ONOFF events for FGEN objects in DCUCOPF scenarios will be mapped to InService=True Events with a corresponding CommitStatus=CYCLING Event.

What will happen if I try to import my Excel data into SAInt v3.9?

Backwards compatibility is not currently supported for Excel import templates.

  • The “InService” property will not be recognized for Network imports. The column header should be changed to InServiceDef
  • ON, OFF, and ONOFF events will not be recognized. They should be configured to control the new properties “InService” and “CommitStatus” as desired.
    • In most cases, the logic behind whether “ON” or “ONOFF” events are used for FGEN objects in DCUCOPF scenarios can be consolidated to the “CommitStatusDef” property in the Network import template.
1 Like