Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

data model prototype (wip) #221

Closed
sanderclaeys opened this issue Feb 10, 2020 · 0 comments · Fixed by #272
Closed

data model prototype (wip) #221

sanderclaeys opened this issue Feb 10, 2020 · 0 comments · Fixed by #272
Assignees
Labels
Category: Data Models Data Models Type: Enhancement New feature or request
Milestone

Comments

@sanderclaeys
Copy link
Contributor

sanderclaeys commented Feb 10, 2020

Discussion points

  • Do we need a vnom property on the buses? This would not be used anywhere in the mathematical model. One option is to non-dimensionalize the bounds with respect to this vnom for convenience.
  • Non-dimensionalize lossy transformer parameters?
  • How to deal with 'different' sub-types with their own specific sets of defined properties? (e.g. load and model)

Shared patterns

  • Each component has a unique (amonst components of the same type) identifier id.
  • Everything is defined in SI units, except when a base is explicitly mentioned in the description.
  • The default sometimes only mentions the default element, not the default value (e.g. true and not fill(fill(true, 3), 3))

Data model

Bus

The data model below allows us to include buses of arbitrary many terminals (i.e., more than the usual four). This would be useful for

  • underground lines with multiple neutrals which are not joined at every bus;
  • distribution lines that carry several conventional lines in parallel (see for example the quad circuits in NEVTestCase).
name default type description
terminals [1,2,3,4] Vector
vm_max / Vector maximum conductor-to-ground voltage magnitude
vm_min / Vector minimum conductor-to-ground voltage magnitude
vm_cd_max / Vector{Tuple} e.g. [(1,2,210)] means |U1-U2|>210
vm_cd_min / Vector{Tuple} e.g. [(1,2,230)] means |U1-U2|<230
grounded [] Vector a list of terminals which are grounded
rg [] Vector resistance of each defined grounding
xg [] Vector reactance of each defined grounding

The tricky part is how to encode bounds for these type of buses. The most general is defining a list of three-tupples. Take for example a typical bus in a three-phase, four-wire network, where terminals=[a,b,c,n]. Such a bus might have

  • phase-to-neutral bounds vm_pn_max=250, vm_pn_min=210
  • and phase-to-phase bounds vm_pp_max=440, vm_pp_min=360 .

We can then define this equivalently as

  • vm_cd_max = [(a,n,250), (b,n,250), (c,n,250), (a,b,440), (b,c,440), (c,a,440)]
  • vm_cd_min = [(a,n,210), (b,n,210), (c,n,210), (a,b,360), (b,c,360), (c,a,360)]

Since this might be confusing for novice users, we also allow the user to define bounds through the following properties.

name default type description
id / unique identifier
phases [1,2,3] Vector
neutral 4 maximum conductor-to-ground voltage magnitude
vm_pn_max / Real maximum phase-to-neutral voltage magnitude for all phases
vm_pn_min / Real minimum phase-to-neutral voltage magnitude for all phases
vm_pp_max / Real maximum phase-to-phase voltage magnitude for all phases
vm_pp_min / Real minimum phase-to-phase voltage magnitude for all phases

Line

This is a pi-model branch.

name default type description
id / unique identifier
n_conductors size(rs)[1] Int>0 number of conductors in this line
f_bus /
f_connections / indicates for each conductor, to which terminal of the f_bus it connects
t_bus /
t_connections / indicates for each conductor, to which terminal of the t_bus it connects
rs / series resistance matrix, size of n_conductors x n_conductors
xs / series reactance matrix, size of n_conductors x n_conductors
g_fr / from-side conductance
b_fr / from-side susceptance
g_to / to-side conductance
b_to / to-side susceptance
c_rating / symmetrically applicable current rating
s_rating / symmetrically applicable power rating

Shunt

name default type description
id / unique identifier
bus /
connections /
g / conductance, size should be |connections|x|connections|
b / susceptance, size should be |connections|x|connections|

Load

name default type description
id / unique identifier
bus /
connections /
configuration / {wye, delta} if wye-connected, the last connection will indicate the neutral
model / indicates the type of voltage-dependency
pd_ref /
qd_ref /
vnom /
exp_p /
exp_q /

Generator

name default type description
id / unique identifier
bus /
connections /
configuration / {wye, delta} if wye-connected, the last connection will indicate the neutral
pg_min / lower bound on active power generation per phase
pg_max / upper bound on active power generation per phase
qg_min / lower bound on reactive power generation per phase
qg_max / upper bound on reactive power generation per phase

AL2W Transformer

These are transformers are assymetric (A), lossless (L) and two-winding (2W). Assymetric refers to the fact that the secondary is always has a wye configuration, whilst the primary can be delta.

name default type description
id / unique identifier
n_phases size(rs)[1] Int>0 number of phases
f_bus /
f_connections / indicates for each conductor, to which terminal of the f_bus it connects
t_bus /
t_connections / indicates for each conductor, to which terminal of the t_bus it connects
configuration / {wye, delta} for the from-side; the to-side is always connected in wye
tm_nom / Real nominal tap ratio for the transformer
tm_max / Vector maximum tap ratio for each phase (base=tm_nom)
tm_min / Vector minimum tap ratio for each phase (base=tm_nom)
tm_set fill(1.0, n_phases) Vector set tap ratio for each phase (base=tm_nom)
tm_fix fill(true, n_phases) Vector indicates for each phase whether the tap ratio is fixed

TODO: add tm stuff

Transformer

These are n-winding, n-phase, lossy transformers. Note that most properties are now Vectors (or Vectors of Vectors), indexed over the windings.

name default type description
id / unique identifier
n_phases size(rs)[1] Int>0 number of phases
n_windings size(rs)[1] Int>0 number of windings
bus / Vector list of bus for each winding
connections Vector{Vector} list of connection for each winding
configurations Vector{{wye, delta}} list of configuration for each winding
xsc 0.0 Vector list of short-circuit reactances between each pair of windings; enter as a list of the upper-triangle elements
rs 0.0 Vector list of the winding resistance for each winding
tm_nom / Vector{Real} nominal tap ratio for the transformer
tm_max / Vector{Vector} maximum tap ratio for each winding and phase (base=tm_nom)
tm_min / Vector{Vector} minimum tap ratio for for each winding and phase (base=tm_nom)
tm_set 1.0 Vector{Vector} set tap ratio for each winding and phase (base=tm_nom)
tm_fix true Vector{Vector} indicates for each winding and phase whether the tap ratio is fixed
@pseudocubic pseudocubic added this to the v0.9.0 milestone Feb 12, 2020
@pseudocubic pseudocubic added Type: Enhancement New feature or request Category: Data Models Data Models labels Feb 12, 2020
pseudocubic added a commit that referenced this issue May 13, 2020
This PR contains the result of a refactor of the default user-facing data model in PowerModelsDistribution to a new `ENGINEERING` data model

A merge of this PR will result in the v0.9.0 release of PowerModelsDistribution

# What is the New Data Model

We have designed a data model that more closely matches the engineering realities of a distribution network, that allows for easy transformation and visualization of the case and includes more component types than are represented in the original (and still existing under the hood) `MATHEMATICAL` data model with which previous users will be familiar.

The new data model is documented in detail in the documentation, including all of the currently supported component types are their individual fields, the types of values, and any defaults we might assume.

# Why Do We Need a New Data Model?

In distribution networks the variety of components in a standard network is much more diverse than in a traditional transmission network, and their mathematical representations are comparatively complex. For example, in order to represent n-winding multiphase transformers with loss models we have to represent a single transformer with a large number of lines, buses, and lossless 2-winding transformers, which previously users have found confusing when attempting to compare their parsed network to the originating file. To simplify the user experience, and to introduce the ability to easily make transformations of the networks, we formulated the `ENGINEERING` data model.

# How Does It Work?

For the most part, the commands that you were using before will not change appreciably. `parse_file` is still the standard way to import data, `run_mc_` commands will still run problem specifications, and PowerModel types should not be different at all. The workflow for most users should be identical; although there are now some intermediate steps to building the JuMP model from the default data dictionary, these steps should be largely invisible to the user unless they want to expose them. Users should experience the following workflow by default:

`parse_file` returns `ENGINEERING` data model -> `run_mc_{}` runs optimization problem and returns result in `ENGINEERING` model format

What is happening behind the scenes is the following:

`parse_file` returns `ENGINEERING` data model -> `run_mc_{}` converts to `MATHEMATICAL` data model in per-unit, builds JuMP model, runs optimization, converts results in `MATHEMATICAL` model format to SI units and converts back to `ENGINEERING` format.

We have exposed to the user the functions that do these conversions if they wish to use them, and have provided examples in Jupyter Notebooks in the `/examples` folder that demonstrates both of these types of workflows.

# If the user experience is the same, what changed besides the default model?

There were a multitude of changes that happened in order to support the functionality for this new data model, as well as some other changes that address concerns and comments of users

- We have eliminated some problem types. This is perhaps one of the biggest changes users will notice; variants of problems like `run_mc_opf_iv` and `run_mc_opf_bf` are eliminated in favor of having users use `run_mc_opf` only, and redirecting to the appropriate problem definitions using multiple dispatch. The only variants that should continue to exist are truly unique problem specifications, _e.g._ `run_mc_opf_oltc` or `run_mc_mld`, etc.
- We have changed the names of variable and constraint functions to support PowerModels v0.17
- We have updated the solution building to use the capabilities in InfrastructureModels v0.5
- We have made updates to the mathematical models for transformers to make them more accurate
- We have added new capabilities to the DSS parser, parsing additional components such as loadshapes, xycurves, xfmrcodes
- We have squashed a lot of outstanding bugs in the DSS parser
- We have ensured that the component naming conventions, particularly for virtual components in the `MATHEMATICAL` model, are consistent across the package
- We have added helper functions to create models from the REPL or scripts, _e.g._ `Model`, `add_bus!`, etc., rather than rely solely on dss inputs (see notebook in `/examples`)
- `parse_dss` originally followed a similar parsing pattern as `parse_pti` in PowerModels, parsing component dictionaries into Vectors. Instead, we now parse into a structure that is much closer to the final data structures that users utilize, in order to make debugging and future parsing easier
- fixed broken SDP/SOC relaxations (see #262)

# Feature X that I want isn't in the new data model

Definitely make a new Github Issue. We view any additions to the data model to be additive and therefore not a breaking change, which means we can make rapid releases containing those additions without any problem.

# Related Issues

Closes #221
Closes #256
Closes #260
Closes #242
Closes #245
Closes #33
Closes #249
Closes #253
Closes #193
Closes #257
Closes #246
Closes #248
Closes #247
Closes #252
Closes #175
Closes #251
Closes #234
Closes #238
Closes #240
Closes #236
Closes #237
Closes #230
Closes #239
Closes #243
Closes #227
Closes #264
Closes #235
Closes #56
Closes #274

Co-authored-by: Sander Claeys <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Data Models Data Models Type: Enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants