Function naming scheme: _tp_

[pseudocubic]

Currently, all PowerModelsDistribution variables/constraints/etc. start with e.g. constraint_tp_, but with the package rename and move to using the conductor name convention in PowerModels, I am not sure tp continues to make sense, especially for the run functions with which most users will actually interact.

I am inclined to use mc for multiconductor, but am open to suggestions, discussion.

@ccoffrin @frederikgeth @sanderclaeys

[sanderclaeys]

I don't feel strong about the specific name; mc seems like a good alternative to tp.

So going forward, the convention is that any constraint that does not take the conductor id as an argument, should start with constraint_mc (or alternative to mc)?

[ccoffrin]

I agree it is good to revisit these constraint names given the package name update. Given our discussion last week I think mc is a good indicator for modeling layer, but the constraint template will likely have to dispatch to more specific constraints like 3p and 3pn for three phase and three phase and a neutral.

We would need to get into the details to understand the best software design, but a simple replacement of _tp_ to _mc_ seems like a good quick fix for now.

[sanderclaeys]

I think it might be a good idea as well to use something like

• mp = multi-phase, for constraints that have no (explicit) neutral and multiple phases
• 3p three-phase, when a constraint is hard-coded for three phases
• mpn/mc multi-conductor, with an explicit neutral (which is the last conductor by convention?)
• 3pn

For now I will use mc everywhere.

[MartaVanin]

Hello,
first of all, thank you a all lot for the very good work you are doing!
I just have a comment wrt this thread: currently in PowerModelsDistribution, the ohms constraints still require a loop over the conductors, even though they contain _tp_ in their name, e.g. constraint_ohms_tp_yt_from(pm::GenericPowerModel, i::Int; nw::Int=pm.cnw, cnd::Int=pm.ccnd).
I understand it is because they need it to account for mutual coupling between different conductors later, but then I find it a bit confusing as the user needs to add the loop explicitly, while the name kind of suggests that it shouldn't be needed.

[pseudocubic]

@MartaVanin this is definitely a good point, and ultimately we hope to correct this issue, see #81 and #61