powsybl / powsybl-dynawo Goto Github PK

• 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

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:

What is the expected behavior?
Including

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

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

We need to specify what do to

Need to update Dynawo version to have this PR dynawo/dynawo#2928 and dynawo/dynawo#2953 and a solution for this issue dynawo/dynawo#2973

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

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

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

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

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

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

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...

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

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

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

• 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

• 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

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

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

• 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

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

• What is the current behavior?
  IIDM XML version has the wrong hard coded value for DynaFlow Security Analysis (1.2 instead of v1.4)

Describe the current behavior

The CLA can only connect to lines

Describe the expected behavior

The CLA can only connect to lines

Describe the motivation

The CLA should connect to any type of quadripole.

Extra Information

No response

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

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

For example for a generator/load or even for a new type of equipment not handled right now as a battery

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

Network should only be use in the context of IIDM

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

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

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

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

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.

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

• What is the current behavior?
  The output of all scenarios is FAILED even when DynaFlow is converging

https://github.com/powsybl/powsybl-dynawo/blob/main/dynawaltz/src/main/java/com/powsybl/dynawaltz/xml/JobsXml.java

If we export curves the curves element does not respect the order of the xsd. An xsd check should be done and curves exported after finalState.

https://github.com/dynawo/dynawo/blob/master/dynawo/sources/API/JOB/xsd/jobs.xsd

And then we can add LoadPQ in the list. Also rename some interface class maybe...

• 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

in models package package no need to add Model suffix in addition

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

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