Comments (4)
I'm not going to comment on whether this is an issue or not, but I can comment on why this is. The wr and wi variables are actually shared between different parallel branches, i.e. only one complex lifted variable $V_i V_j^{}$ = wr+jwi exists for each pair of buses that appear in the topology. (more background see https://arxiv.org/pdf/2202.06449.pdf).
from powermodels.jl.
Yes, and it isn't unreasonable that a variable is reported in a single place.
It isn't a terrible hassle, but when looking for the voltage variables of a line and they do not exist, there is the extra step of finding the parallel line that does have the variables.
In addition, it means that it is easy to make data mistakes when running PowerModels.update_data!()
if it fails to update the voltage variables for the line that does not contain them in the solution dictionary.
I seems like strange behavior and I am wondering if it is intentional.
from powermodels.jl.
This was intentional, but I do think there is room to have a debate around if a better convention is possible.
The guiding principle for the solution data is currently to explicitly report all of the variables in the JuMP model. So for example, if you run an AC-OPF model you get values for the flows on the branches because the S_ij variables are in the model. However, if you run an AC-PF model you do not get the branch flows because these variables are not in the model and are instead represented JuMP expressions. Collections of model variables tend to be 1-to-1 with system components, but there are exceptions from time to time.
As @frederikgeth points out, in some of the convex relaxations the lifted variables are shared across multiple branches. So there is not a nice one-to-one mapping between the variables and the network components. In the case of the SOCWR
model, under the hood a special dict called buspairs
is setup to hold these shared variables.
When it comes to reporting the results in the solution dict the choices I see are,
- Add
buspairs
to the solution data, so it is consistent with how PowerModels works internally - Add the variables from
buspairs
to one representative branch in the system (the current implementation forSOCWR
) - Add the variables from
buspairs
to all branches in the system
I can see pros/cons for each of these choices. Interestingly, in the case of the SDPWRM
models, I was forced to go with option 1, because the SDP models have more variables than branches. So you need to have a separate dict to store them.
I think a bit more debate about possible uses cases / workflows could help us decide if one of these is a better standard for a convention.
@noahrhodes, I am not sure I follow your concern with respect to update_data!
the voltage variables in SOCWR
are always put in the same representative branch, so this should work correctly within to the same relaxation. I do see how there could be inconsistencies when sharing across different relaxations / formulations. However, this may be unavoidable. Can you elaborate a bit more about the workflow(s) you have in mind?
from powermodels.jl.
What I had in mind was passing solution data as initial values between different powerflow type problems and formulations. But you are right that anything re-using W
variables would use the same branch/buspair indexes and any V
variable formulations would need to be post-processed anyways.
from powermodels.jl.
Related Issues (20)
- Generator reactive power limits in PowerModels function compute_ac_pf!() HOT 2
- Not able to solve pti model HOT 2
- solving problems with non-Float64 types HOT 5
- solve_pf() does not work with LPACCPowerModel HOT 3
- There are some doubts about the results of the experiments in the documentation
- Issue with reading Voltage source converter data from PSSE RAW file
- Move data parser to seperate package HOT 2
- Logic makes impedance 0.0 HOT 2
- Precompiling
- Installation of PowerModels with Ipopt support fails on MUSL based systems (Alpine) due to Ipopt HOT 3
- Problem Installing Panda Models HOT 2
- Potential bug in on_off constraints for dcp.jl HOT 5
- use of Pandapower network in PowerModels.jl HOT 3
- Documentation: DCPPowerModel description text HOT 3
- PSSE Parser: incorrect impedance when NOMVX is 0.0 HOT 6
- Performance of make_basic_network HOT 3
- PSS/E parser support transformer angle offset of more than 60 degrees HOT 2
- PSSE Raw files Version 34 HOT 1
- Basic LODF utility? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from powermodels.jl.