search

GRIDAPPSD / GOSS-GridAPPS-D

14 stars 27 forks source link

IEEE123 area assignment incorrect in ContextManager #1683

Closed Tylores closed 1 year ago

Tylores commented 1 year ago

The IEEE123 bus area assignments from the field_interface ContextManager do not give enough switches pairs for some areas resulting in incorrect switch areas for the distributed agents. 

switch_areas = ContextManager.get_context_by_feeder(feeder_id)

I have attached the resulting switch areas, blazegraph query to check assignments, and highlighted actual areas from IEEE123.

switch_areas.txt

bg_query.txt

load_break_switches

ieee123_areas

shpoudel commented 1 year ago

Just as you know, the attached figure shows 5 areas. However, the actual switch areas should be 6. A 61-61s switch is included inside area 3 in the attached figure, which will be a separate area for this case. The attached switch_areas.txt shows eight areas and some incorrect boundary switches.

AAndersn commented 1 year ago

Node 61S will be its own switch area because of the LoadBreakSwitch. Node 610 will be in the secondary area of 61S area, not the orange area 3.

I will test this again today to see if 150 and 150r are being reported in their own switch area also. They are not part of blue area 1 because of the switch, but they are also not part of the feeder area because they are still at the same voltage level (123 node has no substation transformer, only a TapChanger)

I can't tell if there is another switch of a different class (Fuse?) between 300 and 350, but that would also cause 350 to be in a different switch area from blue area 5.

It could be a result of a PR in topology processor that hasn't been merged into ~master. I did some bug fixes for the 123 node on the develop branch a few months ago to build the feeder from the EnergySource instead of PowerTransformer. But I think this is the correct behavior for this feeder.

Tylores commented 1 year ago

'boundary_switches': ['_BC63E102-37AD-4269-BB19-8351403B9B60'] 'boundary_switches': ['_BF5475DE-062E-43B6-8671-8A2EAA5737EE']

issue_areas

These two areas are the issue. I have highlighted them on the map in red.

AAndersn commented 1 year ago

This helps. I'll see why TP thinks there are floating nodes for those two switches:

'connectivity_node': ['_AE099784-C0A6-4534-8596-A09D29715FE1']

'connectivity_node': ['_108D7BE6-6A0B-420C-A95F-99461AB1F9BA']

AAndersn commented 1 year ago

It appears the Topo Processor currently doesn't recognize the difference between a regulator and secondary transformer as they are both TransformerTank objects.

I will create a new ticket to add logic to recognize regulators as a branch and not boundary equipment

AAndersn commented 1 year ago

@Tylores @shpoudel It should be fixed by https://github.com/GRIDAPPSD/topology-processor/commit/1b6e47de23dbf340d238da8d83d63b4731ed4fe1

The TapChanger was represented but not being indexed correctly

AAndersn commented 1 year ago

image

Added a second fix to make make sure that switch terminals were not in another spanning tree before creating a new SA.

https://github.com/GRIDAPPSD/topology-processor/commit/1908ca74a254d70870aa511580ecbc274d30a0e3