powsybl / powsybl-dynawo Goto Github PK
View Code? Open in Web Editor NEWDynawo integration in powsybl
License: Mozilla Public License 2.0
Dynawo integration in powsybl
License: Mozilla Public License 2.0
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:
dyd
fileOmegaRef
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
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
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?
In the dyd file, StandardBus
which corresponds to Bus
library includes
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
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:
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)
Network should only be use in the context of IIDM
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
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.
To have a better code organization.
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?
bug
What is the current behavior?
The output of all scenarios is FAILED even when DynaFlow is converging
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:
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:
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
Feature.
Custom dynamic models cannot be provided to DynaFlow.
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:
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?
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)
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
What is the expected behavior?
Having two separate Classes:
What is the motivation / use case for changing the behavior?
Clear separation of what is purely dynamic from what is linked to static equipment
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.
Fix the variable name generator_deltaPmRefPu_value
No response
No response
No response
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...
GeneratorSynchronousControllable has 6 parents which is greater than the 5 authorized of sonarCloud
The inheritance tree should be with a depth less than 5
No response
No response
No response
No response
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.
A clear error id should appear when the network/solver id is not found in the parameter file
No response
No response
No response
No response
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.
We need to specify what do to
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?
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
Feature.
The dynaflow integration provides an empty list of ComponentResult
, in the LoadFlowResult
.
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.
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?
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)
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
There are two marker interfaces:
GeneratorSynchronousModel
LoadModel
Marker interfaces should be removed as they don't define any behavior, or enriched.
No response
No response
No response
No response
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
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:
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)
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?
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:
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
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,
Running dynawo on a dyd file containing a GeneratorPV
or GeneratorPQ
model crashes.
A simulation containing a GeneratorPV
or GeneratorPQ
should not crash, or that model should be removed from the omegaRefGenerators models list
No response
No response
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 )
No response
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:
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)
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
Running dynawo on a dyd file containing a HvdcPVEmulationVariableK
crashes.
A simulation containing a HvdcPVEmulationVariableK
should not crash, or that model should be removed from the HVDC models list
No response
No response
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 )
No response
For example for a generator/load or even for a new type of equipment not handled right now as a battery
The CLA can only connect to lines
The CLA can only connect to lines
The CLA should connect to any type of quadripole.
No response
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?
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 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?
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
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 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.