Skip to content

SwtControl states are not registered as intended #11

@abodh

Description

@abodh

Summary

I am using the SwtControl to define the Normal state and current State of an existing switch. However, the properties are messed up when I compile the dss file for the first time (Problem 1) and when I change the solution modes (Problem 2).

Package versions

Here are the package versions that I am using:

  • altdss 0.2.4
  • dss-python 0.15.7
  • dss-python-backend 0.14.5
  • opendssdirect-py 0.9.4

Problem 1: Minimal working example

// -------------------------  master.dss ----------------------------------
// ....

// Defining a switch control such that the normal state is closed and the current state is open 
New Line.switch_1 Phases=1 Bus1="101.2" Bus2="102.2" switch="y"
New SwtControl.switch_1 SwitchedObj="Line.switch_1" SwitchedTerm=2 Normal="closed" state="open"

// ...
# ... relevant imports 
> altdss('Compile master.dss')
> altdss.SwtControl['switch_1'].Normal
> <SwtControlState.open: 1> # was expecting closed

> altdss.SwtControl['switch_1'].State
> <SwtControlState.open: 1> # as expected

OpenDSS has this information in its manual for Normal

Normal:
If not Locked, the switch reverts to this state for reset, change of mode, etc. Defaults to first Action or State specified if not specifically declared.

However, that is not the case in our definition and we explicitly define the Normal state as closed.

Potential source of error

I was looking at the dss_capi code for SwtControl and found this. Not sure if I am understanding this well but does this mean that the CurrentAction gets set as the State and Normal is always assigned to CurrentAction? I see a comment that says

// Default to first action specified for legacy scripts

Is there a specific reason to do so?

Problem 2: With change in solution mode: Minimal working example

OpenDSS mentions the following:

  • Reset: {Monitors | Meters | Faults | Controls | Eventlog | Keeplist |(no argument) }
    Resets all Monitors, Energymeters, etc. If no argument specified, resets all options listed.
  • Mode:
    • Side effect: setting the Mode property resets all monitors and energy meters. It also resets the time step, etc. to defaults for each mode. After the initial reset, the user must explicitly reset the monitors and/or meters until another Set Mode= command.
  • Normal:
    If not Locked, the switch reverts to this state for reset, change of mode, etc. Defaults to first Action or State specified if not specifically declared.

So, I assume the controls get reset to its Normal state when changing the solution mode and this is an expected behavior.

# change the solution mode from snap (default) to Yearly
> from altdss.enums import SolutionMode; 
> altdss.Solution.Mode = SolutionMode.Yearly

> altdss.SwtControl['switch_1'].Normal
> <SwtControlState.closed: 2> # as expected

> altdss.SwtControl['switch_1'].State
> <SwtControlState.closed: 2> # was expecting open

I guess this is working as expected for Normal since the control reset (due to change in Solution mode) set the Normal to its original state i.e. closed. However, the current State is also forced to be closed as well i.e. this time State is set as Normal. Is this a normal behavior when the control resets i.e. we lose the current State of the switch?

Questions

  1. Problem 1: the Normal state getting forced to current State during the first compilation is a valid issue or am I missing something?
  2. Problem 2: I want to know the Normal state and current State of the switches for the base case. Is there a way to preserve these states of switches? I cannot access the Normal states of the switches due to Problem 1 and cannot access the current state of switches due to Problem 2. As a workaround, I cache the current state of the switch, perform a forced reset, and then cache the normal state right after compilation but this seems like a patch to my problem than a solution so would appreciate any insights.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions