The iTesla Power System Library is a Modelica library developed as part of the iTesla project. The library contains a set of power system component models for phasor time domain simulations.
License: Mozilla Public License 2.0
Some of the exciters have defined power flow results (terminal voltage) as their parameters. However, this should be done by using ETERM output from the generator model and power flow parameters should be removed from exciter model.
After searching in all models used in REN system we found the problem that prevent the system from initializing.
In iPSL.Electrical.Buses.Bus
It says that the parameter angle_0 is giving in degrees - "Voltage angle (deg)"
And in the PwPin, the real (vr) and imaginary (vi) part of the voltage is using "cos" and "sin" functions from Modelica that work with the argument in radians.
Then, you should add the conversion to radians in the PwPin to start=V_0*cos(angle_0 * pi / 180) and the same for imaginary part.
I found the following in Modelica Doc:
In a top-level class, the version number and the dependency to earlier versions of this class are defined using one or more of the following annotations:
- version = CURRENT-VERSION-NUMBER Defines the version number of the model or package. All classes within this top-level class have this version number.
- conversion ( noneFromVersion = VERSION-NUMBER) Defines that user models using the VERSION-NUMBER can be upgraded to the CURRENT-VERSION-NUMBER of the current class without any changes.
- conversion ( from (version = VERSION-NUMBER, script = "…") ) Defines that user models using the VERSION-NUMBER can be upgraded to the CURRENT-VERSION-NUMBER of the current class by applying the given script. The semantics of the conversion script is not defined.
- uses(IDENT (version = VERSION-NUMBER) ) Defines that classes within this top-level class uses version VERSION-NUMBER of classes within the toplevel class IDENT.
Maybe we should try to implement this, but we need to find out more with the syntax of the script for Dymola. I can already add when there is no conversion needed in the next version.
Implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
source: http://www.uwig.org:8080/index.php?title=Main_Page
It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model.
There is an IMLimitedSimpleLag that should not be there
It should be removed or moved to NonElectrical
@MaximeBaudette I think we should enable the wiki in the same way you did for RaPId.
There we can add the best practices, validation procedure, application guide, training materials, documentation of test systems, papers and thesis from KTH, scripts (e.g. linearization with OM)...
Can you start with this?
We should use this issue also to discuss how the structure of the Wiki needs to be, and what else we will include.
The iPSL GitHub repo is currently lacking a description. This description is used by impact (and impact search page) to display additional information. I've already added a description string to the modelica-3rdparty fork and you might want so simply copy that one or even be slightly more verbose,
Task list for the KundurSMIB system:
The first release "v0.8" is unfortunately not following semantic versioning. Please change that to v0.8.0 and read http://semver.org/ on to why it is so important to always have the three levels. It is essential to follow that in order to be able to resolve dependencies and version conflicts. See also "A follow-up paper Where impact got Going explained the new resolution algorithm used by impact to identify library dependencies"
Implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
source: http://www.uwig.org:8080/index.php?title=Main_Page
It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model.
In models
IPSL.Electrical.Controls.ES.ESST1A and IPSL.Electrical.Controls.ES.IEEEX1
"In the ESST1A model, the imDerivativeLag model is not well initialized : pStartValue must be equal to
Edf0"
We have seen that you have changed the model imDerivativeLag to Modelica.Blocks.Continuous.Derivative. ¿Could you, please, have a look at this?
Thank you.
AIA team.
I have some questions/ doubt about the input of this model.
If you look at this model, one can fix the following parameters:
constant power load
constant shunt admittance load
constant current load
a and b : load transfert fraction for shunt/current load
If you look at PSSE inputs, a and b are not accessible and are deduced from load description.
Moreover, this model does not take care of the input the user choose : use of hard coded parameters
Looking at he iPSL as it could do with some more documentation and a "User's Guide"
Implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
source: http://www.uwig.org:8080/index.php?title=Main_Page
It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model.
The wind package for PSSE is very messy with a lot of sub components that should be moved out of the package and to the NonElectrical package or to the Example package.
@MaximeBaudette
For the conversion from Eurostag we used the following model (in the old library) PowerSystems.Electrical.Loads.PwLoadVoltageDependence that consider alpha and beta parameters in its equations but you have removed it.
We need this model (with alpha, beta parameters) for the conversion from Eurostag so you could put it in a folder called Eurostag.
Hi! Can you add some of the people in my team: @lvanfretti, @MaximeBaudette, @janlav, @tinrabuzin
Please add a link to the iTesla RaPId repo: https://github.com/SmarTS-Lab/iTesla_RaPId
We have a recurrent issue with the library that we develop almost all the time with Dymola and the GIT repository.
The problem is that any minor modification in a single model results in changes in numerous models in their annotations, see Figure:
The problem is that, there are so many of these modifications, it makes the work of making a clean commit so laborious that most of us just commit everything. This is moslty because we don't want to miss one of the real change we have implemented in the code.
The endangers the readibility of the commits, and creates furthers issues when merging branches.
@dietmarw Do you have any idea where this is coming from and how to fix that undesirable behaviour?
Do you know if I can ping someone else to look into this issue.
This is a problem that we've had since the beginning, and wee tried different strategies for getting rid of it (several saving methods, etc.) but never manged to get rid of it
In model IPSL.Electrical.Control.PSS.PSS2A.PSS2A:
1- In the dyr file of REN System, the parameters M and N in the dyr file (PSS/E) are integer but when iTesla module put them in the DDB they are converted into real values. Otherwise in the Modelica model they are integers. ¿Could you define these parameters as Real values in the model?
2- In the dyr file of REN Systems the parameters T_w4 and T_w2 are 0 but in the Modelica model they should be non-zero. In Trello, @tinrabuzin recommended the following:
"For the ImSimpleLag you can put T_6 to 1e-10, and for the washout you can set T_w2 to 1e-10."
For the proper simulation of REN system we need to know if the behaviour of ESST1A will be equal to the expected in PSS/E with T_w2 = 0 and T_w4=0.
(From PSS/E Manual:
Washouts:
To bypass second washout, first signal: set Tw2 = 0
To bypass second washout, second signal: set Tw4 = 0)
Thank you.
AIA team.
@MaximeBaudette ¿Do you have a plan for next releases? For converting REN Systems we need to know when will the next release be ready and if you have a schedule for releases.
Please keep us up to date on the plan. Thanks!
AIA team.
GAST model lacks proper initialisation
I stumbled upon a mistake in the PSAT LOADPQ model concerning the equations related to the change of base.
In all models of the iPSL the following convention must be respected and correctly implemented:
Also we should find a naming convention to distinguish the "internal variables" form the "interface variables", so we don't mix them.
I propose the suffix "_int", so we have: v_int, angle_v_int, P_int, Q_int (if there is a need for such internal variables, not all component require it)
Is the model WT4G1 ready and validated?
Is there an example of validation of Wind turbine WT4G1in the Library to see how they should be connected?
There are numerous WTs in REN system (86 in total) and we are now including them in the conversion.
Please add this to REN Milstone.
AIA team.
I introduced the pfComponent, a partial model providing an harmonized list of parameters for the power flow result :
partial model pfComponent
"Partial model containing all the Data for entering Power Flow data"
outer iPSL.Electrical.SystemBase SysData "Must add this line in all models";
parameter Real V_b = 400 "Base voltage of the bus (kV)"annotation (Dialog(group="Power flow data"));
parameter Real V_0 = 1 "Voltage magnitude (pu)"annotation (Dialog(group="Power flow data"));
parameter Real angle_0 = 0 "Voltage angle (deg)" annotation (Dialog(group="Power flow data"));
parameter Real P_0 = 1 "Active power (MW)" annotation (Dialog(group="Power flow data"));
parameter Real Q_0 = 0 "Reactive power (MVAr)" annotation (Dialog(group="Power flow data"));
parameter Real S_b = SysData.S_b "System base power (MVA)"annotation (Dialog(group="Power flow data", enable=false));
parameter Real fn = SysData.fn "System Frequency (Hz)" annotation (Dialog(group="Power flow data",enable=false));
end pfComponent;The units have been specified in this component, but not yet fully applied to all components (several still use some kind of unspecified per unit system) .
We should implement these units in all models.
I noticed that your library is licensed under LGPL now there is an issue here since LGPL does not allow static linking with other non-lgpl code. This basically means you can not use your library in combination with any other library (including the MSL btw) if you generate an FMU that you like to distribute. There might be other cases. So you might wanna think of re-licensing under MPL which basically allows static linking but is otherwise similar to lgpl. See also the section on this in our impact paper at the last Modelica conference.
Implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
source: http://www.uwig.org:8080/index.php?title=Main_Page
It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model.
In model
iPSL.Electrical.Machines.GENROU:
1- In the Genrou model, when EPDO is calculated, Xpd must be replaced by XPQ.
2- The sign of PSIppq0 must be changed for the calculation of Psiq0
Loading the iPSL library in OpenModelica 1.9.2 produces errors due to mismatches between the name of the folder and the package files. Renaming the folders to match the capitalization in the package name fixes the issue. This produces the following errors:
[2] 13:50:15 Scripting Error
Failed to load package ipsl () using MODELICAPATH C:\Repository\Repos\ipsl;C:/OpenModelica1.9.2/lib/omlibrary.
[3] 13:50:15 Grammar Error
[C:/Repository/Repos/ipsl/ipsl/package.mo: 2:1-28:9]: Expected the package to have name ipsl, but got iPSL.
This can be fixed by renaming the folder to match the capitalization in the package.mo file.
Power Flow solutions for Nordic 44 are not correct. They have to be updated or removed.
Can we keep the capitalisation of the names as it is defined in Modelica (iPSL) and by project (iTesla)? Also, I wasn't sure if I was in the right repository before I looked at the files because of @itesla's profile photo. Can we maybe change this to the iTesla Logo?
In Model
IPSL.Electrical.Controls.PSSE.ES.ESST1A.ESST1A:
1- the pin VUEL2 should be connected to a constant in REN-Systems.
Following KTH developpers this constant (see example IPSL.Examples.PSSE.Configuration.REN.RGroup1_1) have a value of -9999.
RTE recommends to put this value to zero.
2- the imDerivativeLag model is not well initialized : pStartValue must be equal to Edf0
For this a ImPin EFD0 must be declared in the ESST1A model.
Implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
source: http://www.uwig.org:8080/index.php?title=Main_Page
It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model.
@tinrabuzin @MaximeBaudette I would like to address an important issue regarding the approach when changing models that have been through a sw-to-sw validation.
When modifying some "weird" blocks, or something of the model, as you are doing now, we have to be very careful not to affect models related to a domain-specific tool.
If the model has been validated against PSS/E and Eurostag, and modifications are made, we would have to do the validation against the domain specific tool again or compare with the previous implementation.
Otherwise, we can't argue that we can produce similar results than domain specific tools, and this can have a negative impact on user adoption. Remember that one key goal to make this library successful is that the users can have confidence that they will get the same (or better) results than their tool of choice. If we do not take care of this now, we will be faced with more resistance to change from the power system community, and the library will have the same fate as others in the past.
We need to establish a procedure to do this.
I open this issue so that you guys can discuss with @petitrenaudseb @dietmarw @AIAitesla on how to approach this. One suggestion is that we document this through the issue tracker: 1 model = 1 issue.
@jbheyberger and @geofjamg please add your comments about this also.
I am assigning @tinrabuzin and @MaximeBaudette to follow up on this.
As of today the NonElectrical package is badly organized and very redundant. The block's name are difficult to read, and it is hard to find exactly the block one is looking for.
We should discuss:
Implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
source: http://www.uwig.org:8080/index.php?title=Main_Page
It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model.
iPSL.Electrical.Branches.PwLine (and many more) is of typeclass but needs to be changed to a specialized class model.
It has been identified that for some models simulation cannot be completed when there is a fault introduced in the system. In OpenModelica, I noticed that initialization is not done correctly and the simulation fails after a very short time. However, when the fault is removed, initialization and the complete steady-state simulation is correct. Similar problems, to a lesser extend, appear in Dymola also.
Ahsan identified some problems with the fault model too. In order to run his IEEE 9 and 14 bus systems, fault impedance has to be really high.
Therefore, I think that this should be investigated
There is a possibility, in the PSS/E, to use the compensated voltage instead of terminal voltage of the generator as an input to the exciter. Related names of the signals are ECOMP and ETERM.
Those names are used interchangeably in our exciter models and it should be fixed. Most likely, some of the exciter models will not have a proper behaviour if the compensated voltage is used so this needs to be checked as well.
Implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
source: http://www.uwig.org:8080/index.php?title=Main_Page
It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model.
For people interested in contributing towards the library, one important development task is the implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
These modeles are widely used in two domain-specific-tools (PSS/E and PSLF). Yes, I know that there is an IEC Standard for these types of models, and I agree that we should implement and use IEC models. However, one of the most important goals of this library is that actual domain users (power system people) gains confidence in the model of our toolbox, and wether or not everyone likes it, it is a fact that the largest number of engineerings only trust domain-specific tools. Thus, if we are able, as we have done with other models (e.g. generators), we can build this trust with variable generator models that are available in domain-specific tools.
These are models are: http://www.uwig.org:8080/index.php?title=Main_Page
So, anyone willing to contribute to the library doing development, you can start with the link above. It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model, but it is not strictly necessary. @tinrabuzin is developing a compliance checker that creates a PSS/E model from the Modelica model and this allows for automated validation.
If you are willing to help, please get in touch with @MaximeBaudette or @tinrabuzin who can tell you which ones we at SmarTS Lab think are most urgent to get done from different feedback received.
The library still has some "check" errors on the following models:
Should we try to include the iPSL there? @MaximeBaudette
Implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
source: http://www.uwig.org:8080/index.php?title=Main_Page
It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model.
Implementation and sw-to-sw validation of Generic and Domain-Specific-Tool models defined by the Utility Variable-Generation Integration Group.
source: http://www.uwig.org:8080/index.php?title=Main_Page
It is very useful if you have experience and can carry out validation against PSS/E or PSLF to develop the model.
In Model
IPSL.Electrical.Controls.PSSE.ES.ESST1A.ESST1A
the pin VUEL2 should be connected to a constant in REN-Systems.
Following KTH developpers this constant (see example IPSL.Examples.PSSE.Configuration.REN.RGroup1_1) have a value of -9999.
RTE recommends to put this value to zero.
@tinrabuzin we need to upload the test networks we have developed over time.
There are several of them, I think some of them are already in the development examples, however, we could create under examples a folder called test networks with the network models (from what I remember, include):
Let's try to track what is available of larger test networks, and see if I forgot something.
Important
New
Initialisation of the 6th order generator has to be changed.
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.