Comments (14)
Another challenge is how to deal with variable products. It has been convenient to use w for the product of two voltages (i.e. v). But we need a more general rule for the product of other complex numbers.
I suggest if x and y are complex numbers then xy can be represented as,
- xym - suggests xm*ym
- xya - suggests xa + ya
- xyr - suggests xr + yr
- xyi - suggests xi + yi
Due to the convenient existence of w, which looks like vv, we can use it as a shorthand of these cases,
- wm - short for vvm
- wa - short for vva
- wr - short for vvr
- wi - short for vvi
from powermodels.jl.
In light of this convention, and that S is the standard value for complex power, should p and q be renamed sr and si?
from powermodels.jl.
We can do the following: at instances where there is no standard agreed upon naming convention like p and q for sr and si, we can follow your proposed scheme.
from powermodels.jl.
I don't think we can rename p and q as sr and si. To many people "know" what p and q mean, and to replace that may cause too much confusion. I tend to agree with Kaarthik here, where we use sr and si whenever there is not an agreed upon notation.
from powermodels.jl.
If we adopt @kaarthiksundar's suggestion, what is the list of standard agreed upon names?
Another option is for some parameters like p and q to have two aliases for the same set of variables, the typical name and the standardized convention. It's unclear to me if JuMP could handle that.
from powermodels.jl.
@ccoffrin I am pretty (95%) sure JuMP cannot handle that. I have been experimenting with variable names for quite some time and in my experience, that is not possible.
I guess the only agreed upon names are p, q and w.
from powermodels.jl.
It could handle it with some hacks, but would need to be convinced that it's worth making the scoping more complicated and confusing than it already is. You could just use your own dictionary.
from powermodels.jl.
I think if we carefully document that p and q are the exception to the convention (and why), this will be ok. w is a somewhat newer convention, so maybe that can be changed without too much heart burn?
from powermodels.jl.
I like the w notation and It's very nice in the SDP models. I think we have a plan.
- p,q will be the exception to the standard convetion
- w will be the only shorthand, for now
we can revisit multiple aliases at a later time, if this becomes supported in JuMP.
from powermodels.jl.
works for me
from powermodels.jl.
A proposal for dual value naming conventions,
lam
prefix for equality constraints,mu
prefix for inequality constraints- the general template for constraints
<prefix>_<constraint short name>
, if the constraint is a complex quantity then a postfix_<r,i,m,a>
can be added to distinguish - the general template for variable bounds
mu_<var name>_<lb|ub>
Some common examples,
lam_kcl_r
,lam_kcl_i
- KCL at buseslam_ohm_r
,lam_ohm_i
- Omh's law on branchesmu_sm_fr
,mu_sm_to
- thermal limits on branchesmu_vad_lb
,mu_vad_ub
- voltage angle difference limits on branches
from powermodels.jl.
I'd like to make a proposal as well.
Classically, power system people define impedance as z = r + j x and admittance as y = g + j b. At the moment, the parameter symbols defining impedance of a pi-section in PowerModels are like that for the series element. However, c
is used for the shunt susceptance. In more generic context, c
may refer to capacitance, which relates to reactance as x = 1/(2pif*c). This causes unnecessary confusion. I would expect shunt susceptance to be named b
or actually b_sh
to avoid name conflicts.
from powermodels.jl.
@frederikgeth, you make a good point. I think c
is a legacy name we picked up from Matpower. This will be revised to something more reasonable in #214. I am thinking g_fr, b_fr
and g_to, b_to
are what we will end up using for the line charge elements.
from powermodels.jl.
Review the use of underscores in p_dc
and q_dc
, is inconsistent with other variable naming conventions.
from powermodels.jl.
Related Issues (20)
- DCPLL Support for Power Flow Formulations
- Support for Duals of All Constraints
- Drop Support for Run Functions
- Remove obsolete use of `branch_flows` setting
- Ask the question about SOCP model calculations in PowerModels HOT 1
- 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
- How should solutions report square voltage variables for parallel lines HOT 4
- 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
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.