Available models
This page gives an overview about all available models in PowerSystemDataModel. They are basically grouped into two groups:
Input models may be used to describe input data for a power system simulation
Result models denote results of such a simulation
All those models are designed with some assumptions and goals in mind. To assist you in applying them as intended, we will give you some general remarks:
Uniqueness
All models have a uuid
field as universal unique identifier.
There shouldn’t be any two elements with the same uuid
in your grid data set, better in your whole collection
of data sets.
Immutability
We designed the models in a way, that does not allow for adaptions of the represented data after instantiation of the
objects.
Thereby you can be sure, that your models are thread-safe and no unwanted or unobserved changes are made.
Clonability
With the general design principle of immutability, entity modifications (e.g. updates of field values) can become
hard and annoying. To avoid generating methods to update each field value, we provide an adapted version of the
Builder pattern to make entity modifications as easy as possible.
Each entity holds its own copy builder class, which follows the same inheritance as the entity class itself. With a
call of .copy()
on an entity instance a builder instance is returned, which allows for modification of fields and
can be terminated with .build()
. This will return an instance of the entity with modified field values as indicated.
For the moment, this pattern is only implemented for a limited set of entities, but we plan to extend this capability
to all input entities in the future.
Scaling entity properties
Using the copy builders (as described above) we provide a convenience method that helps with scaling system
participants and respective type inputs. Scaling entities tries to preserve proportions that are related to power.
This means that capacity, consumption etc. are scaled with the same factor as power.
Single Point of Truth
Throughout all models you can be sure, that no information is given twice, reducing the possibility to have ambiguous
information in your simulation set up.
“Missing” information can be received through the grids relational information - e.g. if you intend to model a wind
energy converter in detail, you may find information of its geographical location in the model of its common
coupling point (node).
Harmonized Units System
As our models are representations of physical elements, we introduced a harmonized system of units.
The standard units, the models are served with, is given on each element’s page.
Thereby you can be sure, that all information are treated the same.
As most (database) sources do not support physical units, make sure, you have your input data transferred to correct
units before.
Same applies for interpreting the obtained results.
In all models physical values are transferred to standard units on instantiation.
Equality Checks
To represent quantities in the models within an acceptable accuracy, the JSR 385 reference implementation
Indriya is used. Comparing quantity objects or objects holding quantity
instances is not as trivial as it might seem, because there might be different understandings about the equality of
quantities (e.g. there is a big difference between two instances being equal or equivalent). After long discussions how to
treat quantities in the entity equals()
method, we agreed on the following rules to be applied:
equality check is done by calling
Objects.equals(<QuantityInstanceA>, <QuantityInstanceB>)
or<QuantityInstanceA>.equals(<QuantityInstanceB>)
. UsingObjects.equals(<QuantityInstanceA>, <QuantityInstanceB>)
is necessary especially for time series data. As in contrast to all other places, quantity time series from real world data sometimes are not complete and hence contain missing values. To represent missing values this is the only place where the usage ofnull
is a valid choice and hence needs to be treated accordingly. Please remember that this is only allowed in very few places and you should try to avoid usingnull
for quantities or any other constructor parameter whenever possible!equality is given if, and only if, the quantities value object and unit are exactly equal. Value objects can become e.g.
BigDecimal
orDouble
instances. It is important, that the object type is also the same, otherwise the entitiesequals()
method returns false. This behavior is in sync with the equals implementation of the indriya library. Hence, you should ensure that your code always pass in the same kind of a quantity instance with the same underlying number format and type. For this purpose you should especially be aware of the unit conversion methodAbstractQuantity.to(Quantity)
which may return seemingly unexpected types, e.g. if called on a quantity with adouble
typed value, it may return a quantity with a value of eitherDouble
type orBigDecimal
type.for now, there is no default way to compare entities in a ‘number equality’ way provided. E.g. a line with a length of 1km compared to a line with a length of 1000m is actually of the same length, but calling
LineA.equals(LineB)
would returnfalse
as the equality check does NOT convert units. If you want to compare two entity instances based on their equivalence you have (for now) check for each quantity manually using theirisEquivalentTo()
method. If you think you would benefit from a standard method that allows entity equivalence check, please consider handing in an issue Issues. Furthermore, the current existing implementation ofisEquivalentTo()
in indriya does not allow the provision of a tolerance threshold that might be necessary when comparing values from floating point operations. We consider providing such a method in our PowerSystemUtils library. If you think you would benefit from such a method, please consider handing in an issue Issues.
Conditional Parameters
Some of the models have conditional parameters. When reading model data from a data source, their respective factories for building these
models can handle nulls and empty Strings (as well as any combination of those) safely. E.g.: When given parameters for a line’s
operationTime
where operationStartTime
and operationEndTime
are both null
or ""
, the
factory will build an always-on line model.
Validation
Information regarding validation of models can be found here.
Input
Model classes you can use to describe a data set as input to power system simulations.
Additional Data
Some models can use additional data for their calculations.
Result
Model classes you can use to describe the outcome of a power system simulation.
Grid Related Models
Participant Related Models
- Biomass plant
- Combined Heat and Power Plant
- Electric Vehicle
- Electric Vehicle Charging Station
- Fixed Feed In Facility
- Heat Pump
- Load
- Photovoltaic Power Plant
- Electrical Energy Storage
- Wind Energy Converter
- Thermal Sink
- Thermal Storage
- Thermal Unit
- Thermal House
- Cylindrical Thermal Storage
- System Participant
- Flexibility Option
- Energy Management