powsybl / powsybl-incubator Goto Github PK
View Code? Open in Web Editor NEWPowsybl incubator repository
Home Page: https://www.powsybl.org
License: Mozilla Public License 2.0
Powsybl incubator repository
Home Page: https://www.powsybl.org
License: Mozilla Public License 2.0
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:
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) {
}
}
Substation diagram, grid map coloration with TSO specificity.
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?
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:
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?
CSS is embebed in svg.
What is the expected behavior?
We should be able to support 2 modes in SVGWriter:
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?
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:
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?
ComponentType
by a StringGraphBuildPostProcessor
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:
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?
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?
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 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
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
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:
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?
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:
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?
XML converter plugin is missing for new substation and line position extension.
Feature.
The simple loadflow assumes the network has only one connected component, and takes the first bus as the slack bus.
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".
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.
Feature: add a JDBC-based implementation of the AFS interface (AppStorage in particular).
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.
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)
Feature.
The simple loadflow only computes flows using DC approximation.
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.
Being able to use the simple loadflow for tests which imply the availability of voltages / reactive power.
Feature.
GL files are ignored when importing CGMES files.
GL files, which contain geographical data for network equipements, should be imported as new dedicated IIDM extensions.
Being able to display CGMES networks on a map, using those geographical informations.
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:
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:
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?
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.
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.
No export of layout information as DL file.
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 :
Being able to provide layout data to third party tools, together with network model.
Feature.
The simple fload flow implementation uses ojalgo library for its matrix representation and factorization.
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.
Use a common computation module, and performances for larger networks.
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:
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)
Feature.
DL import is implemented as an IIDM post processor.
DL import should instead make use of the ne CGMES import post processor mechanism:
powsybl/powsybl-core#688.
The DL import should be part of the actual CGMES import.
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?
<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).
<polyline id="Wire0" class="substation-diagram-class wire-class Wire0-class" points="..."/>
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg">
<style><![CDATA[ .Wire0-class { stroke: red; }]]></style>
<g>
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"));
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:
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?
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:
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)
Feature.
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.
Being able to exchange data with matpower users community.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.