Skip to content

Implement new generalised type for storing energy bids #36

@BSnelling

Description

@BSnelling

Call this new type EnergyBids for the sake of the issue. EnergyBids would replace the KeyedArray{Vector{Tuple{Float64, Float64}}, 2} that currently represents a set of bids in a System. The keys of these KeyedArrays are bid ids x datetimes and the values are vectors of price-volume pairs ($, pu). Initially this was sufficient to represent the concept of energy bids. In order to support the formulations of other ISOs there are additional requirements for the EnergyBids type:

  • price sensitive bids can still be stored as KeyedArray{Vector{Tuple{Float64, Float64}}, 2} where the axis keys are bid ids x datetimes
  • multi hour bids - bids submitted with a true multi hour flag have to clear as a block (either they all clear or none do), this can be stored in the EnergyBids as a KeyedArray{Int} where the integers act as an id for a block of multi-hour bids
  • fixed bids - bids that are "fixed" must clear at the specified volume or not at all. The alternative is variable type bids which can clear at a volume up to the specified volume. This can be stored in EnergyBids as a KeyedArray{Bool}

So the type would look like:

struct EnergyBids
    """
    Multi-hour block id. In a multi-hour block either all bids clear or none do.
    """
    multi_hour::KeyedArray{Int64, 2}
    """
    Bool indicating whether the bid is a fixed type which can only clear at the given price
    and volume.
    """
    is_fixed_type::KeyedArray{Bool, 2}
    "Bid curve, `KeyedArray` where the axis keys are `generator names x datetimes`."
    bid_curve::KeyedArray{PriceSensitiveBid, 2}
end

Additional requirements

  • it may be useful to have a way to differentiate between supply and demand EnergyBids, either by adding a field to EnergyBids or using subtypes

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions