powsybl / powsybl-incubator Goto Github PK

• Do you want to request a feature or report a bug?

Feature: add a JDBC-based implementation of the AFS interface (AppStorage in particular).

• What is the current behavior?

Only MapDB implementation of AFS is provided.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?

We want to be able to use a relational database as the storage for AFS. As much as possible, the implementation should be vendor-independent. It should rely on a plain JDBC connection and not JPA, in order to keep it a "2 mayers" abstraction, not 3 layers.

• What is the motivation / use case for changing the behavior?

No "production ready" implementation of AFS is available in powsybl-core.

• Please tell us about your environment:

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  There is no way to move a voltage level in JavaFX viewer in a substation diagram.

• What is the expected behavior?
  We should be able to move a voltage level (by dragging it from its label ?)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  When a substation is to big to fit the screen, we have to manually zoomout and pan to see the full diagram.

• What is the expected behavior?
  We must have a button on the right part to automatically fit the substation to screen size.

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  4 labels are automatically added to wire connected to feeders near arrows.

• What is the expected behavior?
  We want to be able to add labels to any node of the graph. To avoid adding too many unused labels to the SVG we could add a configuration object that would be used to determine on which node to add labels, how many labels and relative position of labels from the node. Each label in the SVG would be name according to the node id and a suffix describing the relative position.
  Example for a node id 'hello' =>
  hello_SW_LABEL
  hello_N_LABEL
  ...

The Java object configuration could be something like:

interface LabelConfiguration {

    List<LabelPosition> getLabelPosition(Node node);
}

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Feature

• What is the expected behavior?
  We need a SubstationDiagramStyleProvider implementation (TopologySubstationDiagramStyleProvider) that color the voltage level according to topology => one color per bus.
  Using feature added by #40, we can generate a color scale for each base voltage (so color close to base voltage one) that will be used for bus coloring.

For instance, if we have a 400Kv voltage levels with 2 buses. We need to color differently the 2 buses. If we have defined the color for 400Kv base voltage as red we need to use 2 different variants of the red for the 2 buses.
I think this can be done automatically with something like

• What is the motivation / use case for changing the behavior?
  To see the topology.

• Do you want to request a feature or report a bug?
  A feature

• What is the current behavior?

XML converter plugin is missing for new substation and line position extension.

• Do you want to request a feature or report a bug?

Feature.

• What is the current behavior?

DL import is implemented as an IIDM post processor.

• What is the expected behavior?

DL import should instead make use of the ne CGMES import post processor mechanism:
powsybl/powsybl-core#688.

• What is the motivation / use case for changing the behavior?

The DL import should be part of the actual CGMES import.

• Do you want to request a feature or report a bug?
  A new feature, we need a way to configure in the platform colors corresponding to a base voltage range.

• What is the current behavior?
  It does exist so only solution is to hard code colors which can in reality be different depending of use cases.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  N/A

• What is the expected behavior?
  Is has to be configurable, I would go for a yaml file stored in $HOME/.itools/base-voltages.yml

We need:

• to define a list of base voltage range
• each range has a name
• each range a a color (provided in hexa like #FFFFFFF)
• each range is associated to a profile
• a default profile is speciified

baseVoltage:
    - name: "400"
      minValue: 300
      maxValue: 500
      color: #BBBBBBB
      profile: "RTE"
    - name: "225"
      minValue: 180
      maxValue: 300
      color: #AAAAAAA
      profile: "RTE"

default-profile: "RTE"

A Java API has to be developped to acces this file. Something like:

class BaseVoltageColor {

    List<String> getProfiles() {
    }

    List<String> getBaseVoltageNames(String profile) {
    }

    String getBaseVoltageName(double baseVoltage, String profile) {    
    }
 
    String getColor(String baseVoltageName) {
    }
}

• What is the motivation / use case for changing the behavior?

Substation diagram, grid map coloration with TSO specificity.

• Please tell us about your environment:

  • PowSyBl Version: 2.5.0-SNAPSHOT
  • OS Version: Linux

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

• Do you want to request a feature or report a bug?

bug

• What is the current behavior?
  When dragging a switch the arrows are reversed and misplaced.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?
  Arrows should keep the direction and be placed near to the feeder

• Do you want to request a feature or report a bug?

Feature.

• What is the current behavior?

The simple fload flow implementation uses ojalgo library for its matrix representation and factorization.

• What is the expected behavior?

We should instead use interfaces from powsybl-math, in particular to take advantage of KLU library.
We could also implement that interface for the ojalgo library, to be able to switch between implementations.

• What is the motivation / use case for changing the behavior?

Use a common computation module, and performances for larger networks.

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  In JavafX viewer on left side we have a tree with substation and voltage level. So we can show both substation diagrams and voltage level diagrams. We we want to debug a particular file we like to be able to only have voltage level and being able just with key arrows to browse the full file.

• What is the expected behavior?
  We could have a checkbox somewhere to hide substation in the list in order to only have a list of voltage level.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  A feature.

• What is the current behavior?
  There is no way to visualize flows direction and value on substation diagram.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  N/A

• What is the expected behavior?
  We need to enrich the generated SVG.
  For each wire connected to a feeder node:

  • we generate 4 arrows (2 sets of up and down arrow, spacing has to be configurable) that can be set visible or not (like for switch position). The initial visibility is set according to flow direction (branch.terminalx.p and branch.terminalx.q signs).
  • we generate 4 labels: left and right for the 2 arrow sets. The initial value is set according to flow value (branch.terminalx.p and branch.terminalx.q).

SVG id of arrows (group) and label (text) is:
<ID_OF_EQUIPMENT>_ARROW1_UP
<ID_OF_EQUIPMENT>_ARROW1_DOWN
<ID_OF_EQUIPMENT>_ARROW2_UP
<ID_OF_EQUIPMENT>_ARROW1_DOWN
<ID_OF_EQUIPMENT>_LABEL1
<ID_OF_EQUIPMENT>_LABEL2
<ID_OF_EQUIPMENT>_LABEL3
<ID_OF_EQUIPMENT>_LABEL4

For each busbar section we generate 3 labels (at the 4 corners except the one used for name).
SVG id of busbar section label (text) is:
<ID_OF_BUSBAR_SECTION>_LABEL1
<ID_OF_BUSBAR_SECTION>_LABEL2
<ID_OF_BUSBAR_SECTION>_LABEL3

Initial value for arrow direction and labels comes from a extra class implementing somthing like:

interface SubstationDiagramInitialValueProvider {
  
    Optional<Direction> getArrowDirection1(String feederId);
    Optional<Direction> getArrowDirection2(String feederId);

    Optional<String> getFeederLabel1(String feederId);
    Optional<String> getFeederLabel2(String feederId);
    Optional<String> getFeederLabel3(String feederId);
    Optional<String> getFeederLabel4(String feederId);

    Optional<String> getBusbarSectionLabel1(String busbarSectionId);
    Optional<String> getBusbarSectionLabel2(String busbarSectionId);
    Optional<String> getBusbarSectionLabel3(String busbarSectionId);
}

which could be used like this:

VoltageLevel vl = ...
SubstationDiagram diagram = SubstationDiagram.build(vl);
diagram.writeSvg(new ResourceComponentLibrary(...), 
                             new LayoutParameters() ,
                             new DefaultSubstationDiagramInitialValueProvider(vl)
                             Paths.get("/tmp/a.svg"));

And DefaultSubstationDiagramInitialValueProvider is a default impl that get arrow direction and value from VoltageLevel like specified previously.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

• Do you want to request a feature or report a bug?

Feature.

• What is the current behavior?

The simple loadflow only computes flows using DC approximation.

• What is the expected behavior?

The simple loadflow should have an AC mode, which will compute reactive power and voltages. In order to do this, we must finish the implementation of the computation of the AC matrix, and add iterations ( = Newton Raphson) to the resolution algorithm.

• What is the motivation / use case for changing the behavior?

Being able to use the simple loadflow for tests which imply the availability of voltages / reactive power.

• Do you want to request a feature or report a bug?

Feature.

• What is the expected behavior?

We could be able to export a Network to MatPower case format

It's not obvious if a symmetrical import can be implemented, as case files seem to be matlab files, to be interpreted by matlab.
To be investigated.

• What is the motivation / use case for changing the behavior?

Being able to exchange data with matpower users community.

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Feeder name labels are all drawn at the same height, at the top of external cells. When feeder names are too long they can overlap.

• What is the expected behavior?
  We could alternatively shift label height position to avoid overlapping.

• What is the motivation / use case for changing the behavior?
  To avoid label overlapping.

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  DL are displayed voltage level per voltage level.

• What is the expected behavior?
  As there is now is the data model Graph et SubstationGraph it should be possible to display an entire substation using CGMES DL.

• What is the motivation / use case for changing the behavior?
  To be more compliant with CGMES DL.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  A performance improvement.

• What is the current behavior?
  SVG voltage level diagram is made of individual SVG components, wires and busbar sections assembled together. SVG component are copied in to final SVG, so it means that if we have 10 loads in the substation the SVG symbol of the load is duplicated 10 times.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  N/A

• What is the expected behavior?
  We could reduce the size of the substation SVG by using "refs/use" feature of SVG https://developer.mozilla.org/fr/docs/Web/SVG/Element/use to avoid duplicating component SVG.
  This new feature has to be optional (a parameter in LayoutParameters), because JavaFX SVG rendering library probably (to check) don't support "refs/use".

• What is the motivation / use case for changing the behavior?
  Reduce the SVG size and consequently increase rendering performance.

• Please tell us about your environment:

  • PowSyBl Version: 2.5.0-SNAPSHOT
  • OS Version: Linux

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

• Do you want to request a feature or report a bug?

Feature: the import of DL data into IIDM extensions to be used for the display of voltage levels is implemented. In the future, we will need to be able to create ourselves those DL files.

• What is the current behavior?

No export of layout information as DL file.

• What is the expected behavior?

We should be able to export a DL file together with other CGMES data. This can be done provided we have the necessary data in IIDM extensions. 2 different use cases would be :

• DL file --> IIDM extensions --> DL file
• no layout info --> compute layout info --> IIDM extensions --> DL file

• What is the motivation / use case for changing the behavior?

Being able to provide layout data to third party tools, together with network model.

• Do you want to request a feature or report a bug?

Feature.

• What is the current behavior?

The simple loadflow assumes the network has only one connected component, and takes the first bus as the slack bus.

• What is the expected behavior?

The simple loadflow should compute flows only for the main component, and the slack bus should be chosen inside this main component, possibly with a rule such as "select the most connected bus".

• What is the motivation / use case for changing the behavior?

The current implementation can only work for a network which only has one connected component.
In order to be able to use it for a larger spectrum of test cases, we must make it a little more robust.

• Do you want to request a feature or report a bug?
  A feature

• What is the current behavior?
  SVG style comes from library components and partly hard coded (busbar). There is no easy way to have custom style.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  N/A

• What is the expected behavior?

• component SVG should not have inlined hard coded style. Libraries svg have to cleaned.
• a of list class is added to the svg group when a component is added
  • one global to the voltage level
  • one specfic to the equipment type
  • one specific to the equipment

<g id="XXX" class="substation-diagram-class generator-class XXX-class" transform="...">
</g>

The idea is to be able to define default style for the whole diagram, overloaded if needed with one specific to an equipment and overloaded if needed to one specific to an equipment (for instance for bus coloration).

• consequently it means that we only support one style/color per component which is ok for me.
• same for busbar sections.
• same for wires even if name is automatically generated.

<polyline id="Wire0" class="substation-diagram-class wire-class Wire0-class" points="..."/> 

• style is generated inline in the SVG at the beginning. It allows both easy packaging of the css and also easy modification because everything is centralized in one place in the SVG.

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg">
    <style><![CDATA[ .Wire0-class { stroke: red; }]]></style>
    <g>

• a default behaviour is provided at SVG generation using the following interface:

interface SubstationDiagramStyleProvider {

    String getGlobalStyle(Graph graph);

    String getCompomentStyle(Graph graph, ComponentType componentType);

    String getNodeStyle(Node node);

    String getWireStyle(Edge edge);
}

It can be used like this:

VoltageLevel vl = ...
SubstationDiagram diagram = SubstationDiagram.build(vl);

// to color all equipments of the diagram according to base voltage
diagram.writeSvg(new ResourceComponentLibrary(...), 
                             new LayoutParameters() ,
                             new BaseVoltageSubstationDiagramStyleProvider()
                             Paths.get("/tmp/a.svg"));

// to color equipment according to topology
diagram.writeSvg(new ResourceComponentLibrary(...), 
                             new LayoutParameters() ,
                             new TopologySubstationDiagramStyleProvider()
                             Paths.get("/tmp/a.svg"));

• everything regarding style can be changed on client side for instance in a web client/server architecture, a web service can provide to the client list of node/wire id mapped to buses so that client can update style without regenerating the diagram.

• What is the motivation / use case for changing the behavior?
  To allow displaying additional information on the diagram using style.

• Please tell us about your environment:

  • PowSyBl Version: 2.5.0-SNAPSHOT
  • OS Version: Linux

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  ComponentLibrary manage a set of svg associated to a node in the substation Graph thanks to enum ComponentType. If a substation diagram user wants to add a custom node with a custom rendering, there is no way to do it without forking the source code, adding a new value in the ComponentType enum, add the SVG to the ComponentLibrary and also hack the Graph class to insert the custom node.

• What is the expected behavior?

  • replace ComponentType by a String
  • Add a plugin GraphBuildPostProcessor discovered using java.util.ServiceLoader and that would allow adding custom nodes to the graph.

• What is the motivation / use case for changing the behavior?
  To allow projects to customize substation graph and rendering.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?
  Bug

• What is the current behavior?
  Generated SVG contains duplicated IDs (for instance with switch components open/closed, transformer windings, etc).
  Also in the case where 2 diagrams are displayed in the same web page for instance same voltage level but coming from 2 different network, we also end up with duplicated ids.

• What is the expected behavior?
  All SVG node should have a unique identifier in a diagram.
  In the case of same voltage level from 2 networks, I propose to optionally be able to configure an ID prefix (a String) used by SVGWriter. And that will be the responsibility of the application to defined prefixes passed to SVG generator so that there is no duplication ID.

Network network1 = ...
Network network2 = ...

VoltageLevel vl1 = network1.getVoltageLevel("toto");
VoltageLevel vl2 = network2.getVoltageLevel("toto");

...

new SVGWriter(...).writeSvg("n1_", ...);
new SVGWriter(...).writeSvg("n2_", ...);

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

• Do you want to request a feature or report a bug?

Feature.

• What is the current behavior?

GL files are ignored when importing CGMES files.

• What is the expected behavior?

GL files, which contain geographical data for network equipements, should be imported as new dedicated IIDM extensions.

• What is the motivation / use case for changing the behavior?

Being able to display CGMES networks on a map, using those geographical informations.

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  CSS is embebed in svg.

• What is the expected behavior?
  We should be able to support 2 modes in SVGWriter:

  • embeded CSS like today
  • external CSS

• What is the motivation / use case for changing the behavior?
  With an external CSS it would be easier on client side to animate a diagram (change color, switch position) by just updating CSS part.

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  CSS is provided by SubstationDiagramStyleProvider with Optional.

• What is the expected behavior?
  It would be a cleaner design to to format CSS in SubstationDiagramStyleProvider but having an abstraction like CssWriter and SubstationDiagramStyleProvider could be refactored like this:

public interface SubstationDiagramStyleProvider {

    void writeGlobalStyle(Graph graph, CssWriter cssWriter);

    void writeNodeStyle(Node node, CssWriter cssWriter);

    void writeWireStyle(Edge edge, CssWriter cssWriter);

    void writeNode3WTStyle(Fictitious3WTNode node, ThreeWindingsTransformer.Side side, CssWriter cssWriter);

    void writeNode2WTStyle(Feeder2WTNode node, TwoWindingsTransformer.Side side, CssWriter cssWriter);
}

• What is the motivation / use case for changing the behavior?
  A more robust way to provide CSS and a better way to control how CSS is formatted.

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)