Variable Name Conventions

[ccoffrin]

I propose the following a standard naming convention for the polar and rectangular variable spaces, let "v" be a complex number, then:

• vm - magnitude of v
• va - angle of v
• vr - real component of v
• vi - imaginary component of v

[ccoffrin]

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

[ccoffrin]

In light of this convention, and that S is the standard value for complex power, should p and q be renamed sr and si?

[kaarthiksundar]

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.

[rb004f]

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.

[ccoffrin]

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.

[kaarthiksundar]

@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.

[mlubin]

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.

[rb004f]

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?

[ccoffrin]

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.

[rb004f]

works for me

[ccoffrin]

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 buses
• lam_ohm_r,lam_ohm_i - Omh's law on branches
• mu_sm_fr, mu_sm_to - thermal limits on branches
• mu_vad_lb, mu_vad_ub- voltage angle difference limits on branches

[frederikgeth]

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, cmay 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.

[ccoffrin]

@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.

[ccoffrin]

Review the use of underscores in p_dc and q_dc, is inconsistent with other variable naming conventions.