Skip to content

Element ordering #5

@PMeira

Description

@PMeira

Since the engine current does not reorder the circuit elements, results can be a bit different due to the order of definition of elements. Usually this is more pronounced in bad conditioned system (e.g. when using extra tiny impedances for switches and jumpers).

This would be more useful to reproduce an existing circuit (in DSS scripts), but also a good idea for third-party converters that could provide a good ordering. Some examples would be useful to illustrate the issue, since a lot of people don't get what a bad conditioned matrix is and how it affects the solutions.

We could also add topological ordering in the engine in the future, adding an option to reorder the element for a better matrix, but that would only affect our engine, not the upstream OpenDSS (not for a while, at least).

Two potential solutions:

  1. Add an optional "CircuitOrder" (or something like it) for each circuit element. The name needs to be a very unique name to avoid conflicting with other DSS properties.
  2. Instead of using multiple containers, one for each type of circuit element, glob everything into a simple container. For this, we would need to use a discriminator such as DSSClass that was previously used by default in DSS C-API's JSON dumps.

I like the optional property, but we could end up adding both options down the line.

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