RFC: Define AncillaryServices types to support different sets of ancillary services #33

BSnelling · 2022-10-19T14:49:08Z

Different markets have different sets of ancillary services and related ancillary service requirements.

Let's assume we want one SystemDA type to support multiple markets. The proposal here is to define a type hierarchy for ancillary services that allows us to represent the different ancillary service markets. But this causes a potential difficulty with the accessor functions, because instances of System with different types of AncillaryServices won't have certain ancillary service fields.

The solution to that issue is to have a single accessor for the user to get the ancillary services from the System. Then each AncillaryServices subtype has its own set of accessors.

Example: accessing the regulation offers

# currently - a single accessor acting on `System`
get_regulation_offers(system::System) = system.generator_time_series.regulation_offers

# proposal - the user needs two accessors - one to get AncillaryServices - then another to get the regulation offers
get_ancillary_services(system::System) = system.generator_time_series.ancillary_services
get_regulation_offers(as_offers::FourServices) = as_offers.regulation_offers

BSnelling · 2022-10-19T14:50:21Z

src/system.jl

@@ -2,6 +2,9 @@ const MARKET_WIDE_ZONE = -9999
 const BidName = InlineString31
 const ZoneNum = Int64

+
+abstract type SystemRequirements end


Different sets of ancillary services have different sets of requirements associated with them. So this needs to become a type hierarchy too.

Since the requirements and ancillary services are linked across multiple fields, would it be better to develop the new market as a separate subtype of System to avoid major breaking changes to the package?

I'm debating the pros and cons of that. Having a separate System subtype would keep us free from major breaking changes while developing the second market. On the other hand it's probably good for us to think about common parts of the API from the start, because it'll save us time and energy later when we come to reconcile the two.

BSnelling · 2022-10-19T14:51:02Z

src/system.jl

+    off_supplemental_offers::KeyedArray{Union{Missing, Float64}, 2}
+end
+
+struct FiveServices <: AncillaryServices


FourServices and FiveServices are placeholder names. We can think of something more descriptive.

BSnelling · 2022-10-19T14:53:30Z

src/system.jl

-    loads::KeyedArray{Float64, 2}
+    fixed_loads::KeyedArray{Float64, 2}
+
+    load_services::Union{Missing, LoadTimeSeries}


Another addition we'll have to think about. One market has fixed_loads and no load services, the other has no fixed loads and does have load services which submit ancillary service bids.

Are we likely to get into a situation where we need both? Should we unify them into one field or are the use cases too different?

I believe we won't need both in the new market, they don't have any fixed loads. I am hesitant to unify them though, just because I think they are quite different concepts. I'll need input from Power Systems to be sure on that.

BSnelling · 2022-10-20T09:27:42Z

src/deprecated.jl

@@ -30,3 +30,13 @@ function get_bids(system::SystemDA, type_of_bid::Symbol)
        return getproperty(system, type_of_bid)
    end
 end
+
+@deprecate get_regulation_offers(system::System) get_regulation_offers(get_ancillary_services(system))


We might not want to bother deprecating. I'm not sure it would work well given the name of the function has stayed the same but it acts on a different type in the new design.

Deprecating based on types works just fine. I wouldn't worry too much about getters during an RFC PR though since things might change drastically

morris25 · 2022-10-21T00:15:37Z

src/system.jl

@@ -236,6 +249,39 @@ end

 ###### Time Series types ######

+abstract type AncillaryServices end


As opposed to creating different AncillaryServices types, it might be better to use a more flexible structure. Something like a Dict would allow us to account for markets with any number of services. We could key it with a with a suitable enum or group of singleton types if we needed to limit the possible keys and switch to a more flexible get_offers(::System, ::Service) getter.

Interesting, my concern with a Dict/Dictionary was that the keys would be too unrestricted but using enums or singletons would get around that. I think having the keys defined like that would help a lot with the readability and reliability of the formulation implementation too.

Update: After a chat with our researchers, it seems like we might not need to worry about a separate set of services once we generalize names/practices across markets.

Update to the update: after further research these are indeed subject to change so probably the Dict solution is the safer way to go.

morris25 · 2022-10-21T00:38:18Z

src/system.jl

-    loads::KeyedArray{Float64, 2}
+    fixed_loads::KeyedArray{Float64, 2}
+
+    load_services::Union{Missing, LoadTimeSeries}


Are we likely to get into a situation where we need both? Should we unify them into one field or are the use cases too different?

morris25 · 2022-10-21T00:53:52Z

src/system.jl

@@ -22,7 +25,17 @@ Base.@kwdef struct Zone
    "Zonal good utility practice requirement (regulation + spinning) (pu)"
    good_utility::Float64
 end
-const Zones = Dictionary{ZoneNum, Zone}
+
+struct ZonalRequirements <: SystemRequirements


This split seems off to me. It seems like we might want to view the new market as a single-zone market and either split the set of service requirements into separate types or put them in a more variable structure.

We can still split out Zonal and SystemWide into types, it just feels like we're combining layout and service requirements. We also already have zones in our generators so assuming everything is one big zone could cut down on some workarounds there.

That's a good point. I see how this mixes two different concepts. I think changing it so the new market can be treated as a single zone makes sense. We can ditch the different layout concept for now.

morris25 · 2022-10-21T01:02:21Z

src/system.jl

@@ -2,6 +2,9 @@ const MARKET_WIDE_ZONE = -9999
 const BidName = InlineString31
 const ZoneNum = Int64

+
+abstract type SystemRequirements end


Since the requirements and ancillary services are linked across multiple fields, would it be better to develop the new market as a separate subtype of System to avoid major breaking changes to the package?

morris25 · 2022-10-21T01:06:27Z

src/deprecated.jl

@@ -30,3 +30,13 @@ function get_bids(system::SystemDA, type_of_bid::Symbol)
        return getproperty(system, type_of_bid)
    end
 end
+
+@deprecate get_regulation_offers(system::System) get_regulation_offers(get_ancillary_services(system))


Deprecating based on types works just fine. I wouldn't worry too much about getters during an RFC PR though since things might change drastically

raphaelsaavedra

I'm not particularly a fan of this approach because it seems too rigid. With this we'd have a services type for MISO and one for ERCOT, and we'll probably have one for ISO X once we implement it too, etc. Not to mention, names such as SystemWideRequirements make it seem that we're dealing with a general thing, but it is very much ISO-specific. For example, after these changes Zone still contains regulation, operating_reserve, good_utility which is MISO-specific.

I wonder, why not have it flexible by allowing custom service names to be input? This way we can have the user define what services are there and what are their requirements. For example, let the requirements be defined as a collection (Dict, Array, w/e) of :my_reserve => [(Zone1, 5.0), (Zone2, 10.0), (Zone3, 0.0), (SystemWide, 20.0)] (the data structure doesn't matter here).

use AncillaryServices types, call AS accessors only on AS types

5112185

BSnelling commented Oct 19, 2022

View reviewed changes

BSnelling commented Oct 20, 2022

View reviewed changes

morris25 reviewed Oct 21, 2022

View reviewed changes

BSnelling mentioned this pull request Oct 28, 2022

RFC: subtype System to enable modelling alternative market clearing formulations #34

Open

raphaelsaavedra reviewed Oct 28, 2022

View reviewed changes

BSnelling closed this Nov 7, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: Define AncillaryServices types to support different sets of ancillary services #33

RFC: Define AncillaryServices types to support different sets of ancillary services #33

BSnelling commented Oct 19, 2022 •

edited

Loading

BSnelling Oct 19, 2022

morris25 Oct 21, 2022

BSnelling Oct 21, 2022

BSnelling Oct 19, 2022

BSnelling Oct 19, 2022

morris25 Oct 21, 2022

BSnelling Oct 21, 2022

BSnelling Oct 20, 2022

morris25 Oct 21, 2022

morris25 Oct 21, 2022

BSnelling Oct 21, 2022

morris25 Oct 21, 2022

morris25 Oct 28, 2022

morris25 Oct 21, 2022

morris25 Oct 21, 2022

BSnelling Oct 21, 2022

morris25 Oct 21, 2022

morris25 Oct 21, 2022

raphaelsaavedra left a comment •

edited

Loading

		@@ -236,6 +249,39 @@ end

		###### Time Series types ######

		abstract type AncillaryServices end

RFC: Define AncillaryServices types to support different sets of ancillary services #33

RFC: Define AncillaryServices types to support different sets of ancillary services #33

Conversation

BSnelling commented Oct 19, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raphaelsaavedra left a comment • edited Loading

Choose a reason for hiding this comment

BSnelling commented Oct 19, 2022 •

edited

Loading

raphaelsaavedra left a comment •

edited

Loading