GithubHelp home page GithubHelp logo

powsybl / powsybl-dynawo Goto Github PK

View Code? Open in Web Editor NEW
3.0 3.0 0.0 2.62 MB

Dynawo integration in powsybl

License: Mozilla Public License 2.0

Java 93.88% Groovy 6.12%
energy-system power-system-dynamic-modeling power-system-simulation powsybl powsybl-dynawo

powsybl-dynawo's People

Contributors

abdelhedhili avatar colinepiloquet avatar dependabot[bot] avatar dimbdr avatar flo-dup avatar gautierbureau avatar geofjamg avatar guillemjane-aia avatar jonenst avatar lisrte avatar marcosmc avatar mathbagu avatar miovd avatar olperr1 avatar perninguillaume avatar so-fras avatar zamarrenolm avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

powsybl-dynawo's Issues

[DynaFlow] Additional parameters

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

Feature

  • What is the expected behavior?

When running dynaflow, we should be able to configure the following parameters (as they should appear in a config.json as input to dynaflow):

    "ChosenOutputs" : ["STEADYSTATE", "LOSTEQ", "TIMELINE", "CONSTRAINTS"],
    "VSCAsGenerators": "true",
    "LCCAsLoads": "true",
    "TimeStep": 2.6,

Missing dynawo version check & wrong Dynawaltz provider version

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

  • What is the current behavior?
    Dynawo version check is missing for Security analysis provider and Dynawaltz provider
    Dynawaltz provider version returns a hard coded version based on dynawo version instead of the PowSyBl-Dynawo version

Missing Standard bus connection

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

  • What is the current behavior?
    The dynamic model Standard bus can connect solely with Generators, connection with different models throws an exception.

  • What is the expected behavior?
    Handle connection with other models (to be discussed)

Fix GeneratorPV, GeneratorPQ

Describe the current behavior

Running dynawo on a dyd file containing a GeneratorPV or GeneratorPQ model crashes.

Describe the expected behavior

A simulation containing a GeneratorPV or GeneratorPQ should not crash, or that model should be removed from the omegaRefGenerators models list

Describe the steps

No response

Environment

No response

Relevant Log Output

dynawo logs output:

2023-04-20 10:16:32 | INFO | subModel : OMEGA_REF  Var -omega_grp_3_value- is external and not connected
2023-04-20 10:16:32 | ERROR | missing connection for one/several external variable(s) ( DYNSimulation.cpp:781 )

Extra Information

No response

Contextual information for DSLException

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

  • What is the current behavior?
    When this DSL is not well filled by a user, exceptions are thrown. The message give the field that is not set or invalid, but some contextual information is missing. For instance, staticId or parameterSetId are used for all models and it would be helpful to give more information, for instance the class name (CurrentLimitAutomaton::staticId), and if possible the line number in the script (I don't know if it's possible or not).

  • 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?
    Have more information when there is an error in the DSL

  • What is the motivation / use case for changing the behavior?
    Have a more user-friendly software

  • 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)

Checking dynawo version range

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

  • What is the current behavior?
    The version of dynawo is checked with a minimum version and maximum version supported

  • What is the expected behavior?
    There should be only a minimum version (see #155 discussion)

  • What is the motivation / use case for changing the behavior?
    No need to release powsybl-dynawo for each new release of dynawo

Module refactoring

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

  • What is the current behavior?
    We have a single Maven module

  • What is the expected behavior?
    As discussed with @mathbagu we propose to split the code in 3 Maven modules

  • dynaflow
  • dynawaltz
  • dynawaltz-dsl

The idea behind dynawaltz-dsl is to move everything related to Groovy DSL into its own module and maybe allows using another kind of DSL (like Python or Kotlin one), so that dynaflow and dynawaltz do not have any Groovy dependency.

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

To have a better code organization.

  • 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)

DynaFlow: add StartingPointMode parameter

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

feature

  • What is the current behavior?

  • 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?

Being able to set dynaflow parameter "StartingPointMode". This parameter can take two string values, warm or flat. No default value should be provided

  • 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)

Fix HvdcPVEmulationVariableK

Describe the current behavior

Running dynawo on a dyd file containing a HvdcPVEmulationVariableK crashes.

Describe the expected behavior

A simulation containing a HvdcPVEmulationVariableK should not crash, or that model should be removed from the HVDC models list

Describe the steps

No response

Environment

No response

Relevant Log Output

dynawo output:

2023-04-20 08:35:03 | INFO | subModel : HVDC2  Var -acemulation_KACEmulation- is external and not connected
2023-04-20 08:35:03 | ERROR | missing connection for one/several external variable(s) ( DYNSimulation.cpp:781 )

Extra Information

No response

Ensure equipments - dynamicModels associations

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

  • What is the current behavior?
    With the current implementation it's allowed to associate a dynamic model to an equipment that doesn't exist or an invalid equipment (associate a generator model to a line). Currently, there is no check in the DSL and the errors in the logfile is not easy to understand from a user point of view (the number of equations is not OK).

  • 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?
    Check that the staticId exists in the network and the equipment type is compatible

  • What is the motivation / use case for changing the behavior?
    Have a more user-friendly software

  • 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)

Is it relevant to have a maximum version of DynaFlow?

Why is there a maximum version for DynaFlow?
I would have expected to have only a minimum version (versions of DynaFlow before this minimum version are not compatible anymore) . It means that to test the behavior with the development version of DynaFlow an user has to change powsybl code.

Independently from the answer to this question the maximum version of DynaFlow needs to be updated to v1.4.0.

Marker interfaces

Describe the current behavior

There are two marker interfaces:

  • GeneratorSynchronousModel
  • LoadModel

Describe the expected behavior

Marker interfaces should be removed as they don't define any behavior, or enriched.

Describe the steps

No response

Environment

No response

Relevant Log Output

No response

Extra Information

No response

Enforce unique MacroStaticReference for each dynamic model

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

  • What is the current behavior?
    Nothing ensures that a model has the same MacroStaticReference for all of his instances. Only one is kept for all instances when dyd is written, as it is indexed in the corresponding map by the lib name.

  • What is the expected behavior?
    One model has the same MacroStaticReference for all of his instances

  • What is the motivation / use case for changing the behavior?
    Having by design a unique MacroStaticReference for each dynamic model

[DynaFlow] Models configuration

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

Feature.

  • What is the current behavior?

Custom dynamic models cannot be provided to DynaFlow.

  • What is the expected behavior?

We would like to be able to configure custom dynamic models in order to get the maximum added value out of DynaFlow.

Without knowing the tool well enough, I can imagine 2 ways of providing such configuration to the loadflow API:

  1. By providing files path (for assembling/dyd/settings files ?) in dynaflow config or parameters
  2. By providing models definitions in IIDM extensions

The 2 approaches may be complementary.
The design is clearly open for discussion, this is the goal of the present issue.

DynaFlow version checking is not working properly

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

  • What is the current behavior?
    When I try to run powsybl-dynawo with DynaFlow development branch I get the following error:

> util/envPowSyblTest.sh loadflow --case-file microGridType4BE.xiidm --config-name config
Loading network 'microGridType4BE.xiidm'
com.powsybl.commons.PowsyblException: DynaFlow version not supported. Must be >= 1.4.0

However the dynaflow version is above 1.4.0:

dynaflow-launcher.sh --version
1.5.0 (rev:564_mpi-2acffd2)

[DynaFlow] Report component results

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

Feature.

  • What is the current behavior?

The dynaflow integration provides an empty list of ComponentResult, in the LoadFlowResult.

  • What is the expected behavior?

We should try to provide information about the executed computations in component results.
In particular, knowing the status of the computation on network components will be very important for users.

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

In particular, being able to know if the computation has been successful or not.

Implementation question
Does it require an evolution in DynaFlow to retrieve those informations ?

Wrong GeneratorPV variable name

Describe the current behavior

GeneratorPV corresponds to OmegaRefGeneratorControllable java class, which returns generator_deltaPmRefPu_value for getDeltaPVarName(). This variable is not known on dynawo side, leading to an explicit error.

Describe the expected behavior

Fix the variable name generator_deltaPmRefPu_value

Describe the steps

No response

Environment

No response

Relevant Log Output

No response

Extra Information

No response

Typing variable names in pairing lists

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

What is the current behavior?
BlackBoxModel::getVarsMapping and BlackBoxModel::getVarsConnect return a list of Pair<String, String>

What is the expected behavior?

  • BlackBoxModel::getVarsMapping returns a list of Pair<StaticVariable, DynamicVariable>
  • BlackBoxModel::getVarsConnect returns a list of Pair<DynamicVariable, DynamicVariable>

What is the motivation / use case for changing the behavior?
Clear API

Synchronous generators config file

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

What is the current behavior?
The synchronous generators supported in groovy are listed in a synchronous_generators.cfg file in resources.

What is the expected behavior?
The synchronous generator models supported in groovy can be listed in a file whose path can be passed on or configured

What is the motivation / use case for changing the behavior?
Add new supported synchronous generators without the need of a new release

Other information
The models could maybe be listed in

  • a file specified in dynawaltz platform config
  • a file passed on as a GeneratorModelGroovyExtension constructor parameter? if somebody wants to extend this class for instance with another config file

Missing attributes in StandardBus

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

What is the current behavior?
In the dyd file, StandardBus which corresponds to Bus library includes

  • no macro static reference
  • no parameterSetId

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
Include a StandardBus and look at the dyd generated file. See for instance DynamicModelsXmlTest::writeDynamicModel with reference file:

<dyn:blackBoxModel id="BBM_NGEN" lib="Bus" staticId="NGEN"/>

What is the expected behavior?
Including

  • Macro static references
  • parameterSetId
    Or add comment explaining why those parameters are not needed.

Improve log in OmegaRef

Upon double h = dynaWaltzParameters.getModelParameters(generator.getParameterSetId()).getDouble("generator_H"); we can get a java.util.concurrent.CompletionException: java.lang.NullPointerException, would be good to test if the parameterSet is present and then test if the parameter is there...

OmegaRef single instance

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

What is the current behavior?
An instance of OmegaRef is created for each generator model, with some "very special magic" as said in the comments:

  • all instances have the same id so that it is written only once in the dyd file
  • the OmegaRef which is retained in the DynaWaltzContext dynamicId map needs to access the others when writing the parameters: this is done thanks to the DynaWaltzXmlContext which returns a list of all BlackBoxModels
  • the index of each generator is dubious: nothing really ensures so far that it is the same index for one generator in the OmegaRef::writeParameters and in the ``OmegaRef::writeMacroConnect`

What is the expected behavior?
Having a single instance of OmegaRef

What is the motivation / use case for changing the behavior?
Fix the "special magic" and the dubious generator index, and reflect the unicity of OmegaRef on dynawo side.

Other information
This will need some "special magic" on groovy side, as we don't want to change its syntax. Nonetheless, what's next is to delete the access to OmegaRef in the groovy, and deal with it automatically when a generator mapping is defined, so that the user does not care about this: see issue #116

Aliases for long keywords

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

  • What is the current behavior?
    Some keywords in the DSL are really long. Most of them correspond to the name of the dynamic model in Dynawo. It's really easy to write the wrong name that lead to a syntax error, but it could be nice if the user (or the integration) has a way to define its own alias.

  • 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?
    Be able to define custom aliases for really long keywords to avoid mistyping:

alias gs4w = GeneratorSynchronousFourWindings
  • What is the motivation / use case for changing the behavior?
    Make the DSL more user-friendly

  • 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)

No clear feedback given to user when referencing a parameter set id not available in dynawaltz inputs parameters files

Describe the current behavior

The user has to provide a parameter file and a parameter id for the network and the solver in the DynaWaltz configuration. When the parameter id is not avaialable in the parameter file powsybl-dynawo goes on without any error or warning.

Describe the expected behavior

A clear error id should appear when the network/solver id is not found in the parameter file

Describe the steps

No response

Environment

No response

Relevant Log Output

No response

Extra Information

No response

Wrong attribute in Line model

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

  • What is the current behavior?
    Line dynamic model classes have a side attribute used mainly by current limit automaton.

  • What is the expected behavior?
    The side attribute should be defined only by models connected to the side of a line.

Induced OmegaRef instantiating

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

  • What is the current behavior?
    OmegaRef needs to be instantiated for each generator. If missing, dynawaltz simulation won't succeed.

  • What is the expected behavior?
    OmegarRef induced instantiating

  • What is the motivation / use case for changing the behavior?
    Ease up the dynamic mapping as OmegaRef instance can be deduced from generator dynamic models mapping

Windows CLI error calling dynawaltz

  • Do you want to request a feature or report a bug?
    Bug on windows 10 with dynawo 1.3.1

  • What is the current behavior?
    When launching a dynawaltz simulation dynawo.cmd is called with the argument "--jobs-file C:/path/to/tmp/file.jobs" and the subprocess crashes with a single message in the .err file translated as: "else was not expected"

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

  1. Clone this repo
  2. Download dynawo 1.3.1 from dynawo website.
  3. Add "homeDir: /YOUR/PATH/TO/DYNAWO/" to the dynawaltz section of config.yml
  4. Run Main.java
  • What is the expected behavior?
    The simple Main should be able to launch dynawaltz on windows and dynawo
    this method should update to the new argument of dynawo on windows

  • Please tell us about your environment:

    • PowSyBl Version: 1.10.0 in the example
    • OS Version: windows 10
  • fix ideas
    Detect the version of dynawo to match the correct syntax of windows ("--jobs-file" for older version, "jobs" now)
    Another issue causing this seems to come from cmd parsing :

  • D:\POWSYBL\dynawo\dynawo.cmd "jobs" "C:\pow\powsybl_dynawaltz.jobs" does not work in cmd but works in powershell

  • D:\POWSYBL\dynawo\dynawo.cmd "jobs" C:\pow\powsybl_dynawaltz.jobs does work in cmd and in powershell

Separate pure dynamic Models from dynamic with static reference Models

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

What is the current behavior?
Pure dynamic Models and dynamic with static reference Models inherits from the same BlackBoxModel, but

  • pure dynamic models have en empty string as staticId, reflecting the optional staticId in dynawo blackBoxModels
  • pure dynamic models return an empty list of varsMapping, reflecting the optional corresponding MacroStaticRef

What is the expected behavior?
Having two separate Classes:

  • one for pure dynamic Models
  • one for dynamic with static reference Models

What is the motivation / use case for changing the behavior?
Clear separation of what is purely dynamic from what is linked to static equipment

Deep inheritance tree

Describe the current behavior

GeneratorSynchronousControllable has 6 parents which is greater than the 5 authorized of sonarCloud

Describe the expected behavior

The inheritance tree should be with a depth less than 5

Describe the steps

No response

Environment

No response

Relevant Log Output

No response

Extra Information

No response

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.