diff --git a/.gitattributes b/.gitattributes
index cbac638a7..51769a21f 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -3,3 +3,4 @@
src/test/resources/edu/ie3/datamodel/io/source/influxdb/_weather/cosmo/weather.txt eol=lf
src/test/resources/edu/ie3/datamodel/io/source/influxdb/_weather/icon/weather.txt eol=lf
+gradlew eol=lf
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index 3ba92939b..522a1ae52 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -13,10 +13,6 @@ updates:
- sebastian-peter
- danielfeismann
- jo-bao
- ignore:
- - dependency-name: org.spockframework:spock-core
- versions:
- - 2.3-groovy-4.0
- package-ecosystem: pip
directory: "/docs/readthedocs"
diff --git a/.readthedocs.yaml b/.readthedocs.yaml
index 90e935b33..e169b21e7 100644
--- a/.readthedocs.yaml
+++ b/.readthedocs.yaml
@@ -7,9 +7,9 @@ version: 2
# Set the version of Python and other tools you might need
build:
- os: ubuntu-20.04
+ os: ubuntu-22.04
tools:
- python: "3.9"
+ python: "3.11"
# Configure python
python:
@@ -18,4 +18,5 @@ python:
# Build documentation in the docs/ directory with Sphinx
sphinx:
- configuration: docs/readthedocs/conf.py
\ No newline at end of file
+ configuration: docs/readthedocs/conf.py
+ fail_on_warning: true
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 046e514b6..168dafc71 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,27 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
## [Unreleased/Snapshot]
+## [4.0.0] - 2023-08-01
+
+### Added
+- Copy methods for container classes [#726](https://github.com/ie3-institute/PowerSystemDataModel/issues/726)
+- Allow hierarchic grid structure for JointGridContainer [#768](https://github.com/ie3-institute/PowerSystemDataModel/issues/768)
+- Adding SQL id coordinate sources (``IdCoordinateSource``) [#689](https://github.com/ie3-institute/PowerSystemDataModel/issues/689)
+- Added some standard asset types to documentation [#642](https://github.com/ie3-institute/PowerSystemDataModel/issues/642)
+
+### Fixed
+- Fixed wrong rated power unit hint [#804](https://github.com/ie3-institute/PowerSystemDataModel/issues/804)
+- Fixed wrong hash code generation of ConnectorResult [#817](https://github.com/ie3-institute/PowerSystemDataModel/issues/817)
+
+### Changed
+- Removing deprecated classes and methods [#540](https://github.com/ie3-institute/PowerSystemDataModel/issues/540)
+- Refactor CSV data sources [#716](https://github.com/ie3-institute/PowerSystemDataModel/issues/716)
+- Deleted parameter initFiles, set parameter append to false by default [#791](https://github.com/ie3-institute/PowerSystemDataModel/issues/791)
+- Use nio paths instead of strings for file path [#723](https://github.com/ie3-institute/PowerSystemDataModel/issues/723)
+- Data source will throw an exceptions instead of returning an empty optionals [#707](https://github.com/ie3-institute/PowerSystemDataModel/issues/707)
+- Improving `ValidationUtils` [#758](https://github.com/ie3-institute/PowerSystemDataModel/issues/758)
+
+
## [3.0.0] - 2023-02-16
### Added
@@ -25,26 +46,26 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
### Fixed
- Reduced code smells [#492](https://github.com/ie3-institute/PowerSystemDataModel/issues/492)
- - Protected constructors for abstract classes
- - Use pattern matching
- - Remove unused imports
- - Use enhanced switch statements
- - Replace lambdas with method references
- - Use `Stream#toList`
- - Adapt visibility for JUnit 5
+ - Protected constructors for abstract classes
+ - Use pattern matching
+ - Remove unused imports
+ - Use enhanced switch statements
+ - Replace lambdas with method references
+ - Use `Stream#toList`
+ - Adapt visibility for JUnit 5
- More code smell fixing [#633](https://github.com/ie3-institute/PowerSystemDataModel/issues/633)
- - Use `List#of`
- - Use direct assignment with switch/case structures
- - Turn some classes into records
- - Making abstract classes' constructor protected
- - Improving some RegExs
- - Replacing `filter(Optional::isPresent).map(Optional::get)` on streams with `flatMap(Optional::stream)`
- - instanceof variable declarations
- - Removing unnecessary parentheses
- - Miscellaneous code smells
+ - Use `List#of`
+ - Use direct assignment with switch/case structures
+ - Turn some classes into records
+ - Making abstract classes' constructor protected
+ - Improving some RegExs
+ - Replacing `filter(Optional::isPresent).map(Optional::get)` on streams with `flatMap(Optional::stream)`
+ - instanceof variable declarations
+ - Removing unnecessary parentheses
+ - Miscellaneous code smells
- Fix JavaDoc creation
- - Create JavaDoc with java 17 instead of java 8
- - Let JavDoc pass, if there are warnings **ATTENTION:** Should be removed, when JavaDoc is fixed! (cf. Issue [#494](https://github.com/ie3-institute/PowerSystemDataModel/issues/494))
+ - Create JavaDoc with java 17 instead of java 8
+ - Let JavDoc pass, if there are warnings **ATTENTION:** Should be removed, when JavaDoc is fixed! (cf. Issue [#494](https://github.com/ie3-institute/PowerSystemDataModel/issues/494))
- `BufferedCsvWriter` writes columns in the order, that the headline elements are defined [#434](https://github.com/ie3-institute/PowerSystemDataModel/issues/393)
- Cleaned up `IndividualTimeSeriesMetaInformation`-related methods in `CsvFileConnector` [#544](https://github.com/ie3-institute/PowerSystemDataModel/issues/544)
- Fixed spotlessApply handling for `.groovy` files [#637](https://github.com/ie3-institute/PowerSystemDataModel/issues/637)
@@ -65,18 +86,19 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
- `edu.ie3.datamodel.io.connectors.CsvFileConnector.CsvIndividualTimeSeriesMetaInformation`
- and related methods
- BREAKING: Comprehensive harmonization around weather sources [#267](https://github.com/ie3-institute/PowerSystemDataModel/issues/267)
- - Adapted the expected column scheme
- - General weather model
- - `coordinate` to `coordinateid`
- - DWD COSMO model
- - `diffuseirradiation` to `diffuseirradiance`
- - `directirradiation` to `directirradiance`
- - ICON model:
- - `"datum"` to `"time"`
- - Force user to provide time stamp pattern to `CouchbaseWeatherSource` to ensure harmonized querying
+ - Adapted the expected column scheme
+ - General weather model
+ - `coordinate` to `coordinateid`
+ - DWD COSMO model
+ - `diffuseirradiation` to `diffuseirradiance`
+ - `directirradiation` to `directirradiance`
+ - ICON model:
+ - `"datum"` to `"time"`
+ - Force user to provide time stamp pattern to `CouchbaseWeatherSource` to ensure harmonized querying
- BREAKING: Updating PowerSystemUtils dependency to 2.0-SNAPSHOT [#595](https://github.com/ie3-institute/PowerSystemDataModel/issues/595)
- BREAKING: Generified the `LoadInput` attribute `standardLoadProfile` to `loadProfile` as it should also address the newly added `TemperatureDependantLoadProfile`s [#601](https://github.com/ie3-institute/PowerSystemDataModel/issues/601)
- Adapted to new double converters in PSU [#705](https://github.com/ie3-institute/PowerSystemDataModel/issues/705)
+- Setting fixed groovy version and updating groovy [#788](https://github.com/ie3-institute/PowerSystemDataModel/issues/788)
## [2.1.0] - 2022-01-05
@@ -92,6 +114,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
- Writers used to write time series are closed right away
- Changed class name in FlexOptionsResult.toString [#693](https://github.com/ie3-institute/PowerSystemDataModel/issues/693)
- Deleted parameter decimalPlaces and changed naming of serialization method [#710](https://github.com/ie3-institute/PowerSystemDataModel/issues/710)
+- Changed switch result documentation according to the implementation [#757](https://github.com/ie3-institute/PowerSystemDataModel/issues/757)
+- Added documentation for EmResult and FlexOptionResult [#656](https://github.com/ie3-institute/PowerSystemDataModel/issues/656)
## [2.0.1] - 2021-07-08
@@ -195,7 +219,8 @@ coordinates or multiple exactly equal coordinates possible
- CsvDataSource now stops trying to get an operator for empty operator uuid field in entities
- CsvDataSource now parsing multiple geoJson strings correctly
-[Unreleased/Snapshot]: https://github.com/ie3-institute/powersystemdatamodel/compare/3.0.0...HEAD
+[Unreleased/Snapshot]: https://github.com/ie3-institute/powersystemdatamodel/compare/4.0.0...HEAD
+[4.0.0]: https://github.com/ie3-institute/powersystemdatamodel/compare/3.0.0...4.0.0
[3.0.0]: https://github.com/ie3-institute/powersystemdatamodel/compare/2.1.0...3.0.0
[2.1.0]: https://github.com/ie3-institute/powersystemdatamodel/compare/2.0.1...2.1.0
[2.0.1]: https://github.com/ie3-institute/powersystemdatamodel/compare/2.0.0...2.0.1
diff --git a/build.gradle b/build.gradle
index efe690fb9..6a804d47d 100644
--- a/build.gradle
+++ b/build.gradle
@@ -4,19 +4,21 @@ plugins {
id 'maven-publish'
id 'signing'
id 'pmd' // code check, working on source code
- id 'com.diffplug.spotless' version '6.15.0'//code format
- id 'com.github.spotbugs' version '5.0.13' // code check, working on byte code
- id 'de.undercouch.download' version '5.3.1'
+ id 'com.diffplug.spotless' version '6.20.0'//code format
+ id 'com.github.spotbugs' version '5.1.0' // code check, working on byte code
+ id 'de.undercouch.download' version '5.4.0'
id 'kr.motd.sphinx' version '2.10.1' // documentation generation
id 'jacoco' // java code coverage plugin
- id "org.sonarqube" version "3.5.0.2730" // sonarqube
+ id "org.sonarqube" version "4.3.0.3225" // sonarqube
id 'net.thauvin.erik.gradle.semver' version '1.0.4' // semantic versioning
}
ext {
//version (changing these should be considered thoroughly!)
javaVersion = JavaVersion.VERSION_17
- testcontainersVersion = '1.17.6'
+ groovyVersion = "4.0"
+ groovyBinaryVersion = "4.0.13"
+ testcontainersVersion = '1.18.3'
scriptsLocation = 'gradle' + File.separator + 'scripts' + File.separator //location of script plugins
}
@@ -43,7 +45,6 @@ repositories {
// sonatype snapshot repo
maven { url 'https://s01.oss.sonatype.org/content/repositories/snapshots' }
-
}
dependencies {
@@ -51,7 +52,7 @@ dependencies {
// ie³ power system utils
implementation 'com.github.ie3-institute:PowerSystemUtils:2.0'
- implementation 'tech.units:indriya:2.1.4'
+ implementation 'tech.units:indriya:2.2'
// JTS Topology Suite for GeoPositions, License: EPL 1.0 / EDL 1.0
implementation ('org.locationtech.jts:jts-core:1.19.0'){
@@ -61,13 +62,15 @@ dependencies {
implementation 'org.locationtech.jts.io:jts-io-common:1.19.0'
// Graphs
- implementation 'org.jgrapht:jgrapht-core:1.5.1'
+ implementation 'org.jgrapht:jgrapht-core:1.5.2'
// testing
- testImplementation 'org.junit.jupiter:junit-jupiter:5.9.2'
- testImplementation 'org.spockframework:spock-core:2.3-groovy-3.0'
+ testImplementation "org.apache.groovy:groovy:$groovyBinaryVersion"
+
+ testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0'
+ testImplementation "org.spockframework:spock-core:2.3-groovy-$groovyVersion"
testImplementation 'org.objenesis:objenesis:3.3' // Mock creation with constructor parameters
- testImplementation 'net.bytebuddy:byte-buddy:1.13.0' // Mocks of classes
+ testImplementation 'net.bytebuddy:byte-buddy:1.14.5' // Mocks of classes
// testcontainers (docker framework for testing)
testImplementation "org.testcontainers:testcontainers:$testcontainersVersion"
@@ -77,20 +80,19 @@ dependencies {
testImplementation "org.testcontainers:couchbase:$testcontainersVersion"
// logging
- implementation platform('org.apache.logging.log4j:log4j-bom:2.19.0')
+ implementation platform('org.apache.logging.log4j:log4j-bom:2.20.0')
implementation 'org.apache.logging.log4j:log4j-api' // log4j
implementation 'org.apache.logging.log4j:log4j-core' // log4j
implementation 'org.apache.logging.log4j:log4j-slf4j-impl' // log4j -> slf4j
// Databases
implementation 'org.influxdb:influxdb-java:2.23'
- implementation 'com.couchbase.client:java-client:3.4.3'
- runtimeOnly 'org.postgresql:postgresql:42.5.3' // postgresql jdbc driver required during runtime
-
- implementation 'commons-io:commons-io:2.11.0' // I/O functionalities
- implementation 'org.apache.commons:commons-compress:1.22' // I/O functionalities
- implementation 'org.apache.commons:commons-lang3:3.12.0'
+ implementation 'com.couchbase.client:java-client:3.4.8'
+ runtimeOnly 'org.postgresql:postgresql:42.6.0' // postgresql jdbc driver required during runtime
+ implementation 'commons-io:commons-io:2.13.0' // I/O functionalities
+ implementation 'org.apache.commons:commons-compress:1.23.0' // I/O functionalities
+ implementation 'org.apache.commons:commons-lang3:3.13.0'
}
tasks.withType(JavaCompile) {
diff --git a/docs/readthedocs/_static/figures/uml/DataSourceClassDiagram.png b/docs/readthedocs/_static/figures/uml/DataSourceClassDiagram.png
index c1a91f912..8ea07c880 100644
Binary files a/docs/readthedocs/_static/figures/uml/DataSourceClassDiagram.png and b/docs/readthedocs/_static/figures/uml/DataSourceClassDiagram.png differ
diff --git a/docs/readthedocs/_static/figures/uml/EntitySourceClassDiagram.png b/docs/readthedocs/_static/figures/uml/EntitySourceClassDiagram.png
new file mode 100644
index 000000000..19a94ff8e
Binary files /dev/null and b/docs/readthedocs/_static/figures/uml/EntitySourceClassDiagram.png differ
diff --git a/docs/readthedocs/_static/figures/uml/FunctionalDataSourceClassDiagram.png b/docs/readthedocs/_static/figures/uml/FunctionalDataSourceClassDiagram.png
new file mode 100644
index 000000000..8dca730c3
Binary files /dev/null and b/docs/readthedocs/_static/figures/uml/FunctionalDataSourceClassDiagram.png differ
diff --git a/docs/readthedocs/_static/figures/uml/TimeSeriesSourceClassDiagram.png b/docs/readthedocs/_static/figures/uml/TimeSeriesSourceClassDiagram.png
new file mode 100644
index 000000000..b111fb370
Binary files /dev/null and b/docs/readthedocs/_static/figures/uml/TimeSeriesSourceClassDiagram.png differ
diff --git a/docs/readthedocs/_static/figures/uml/WeatherCoordinateSourceClassDiagram.png b/docs/readthedocs/_static/figures/uml/WeatherCoordinateSourceClassDiagram.png
new file mode 100644
index 000000000..7f657673a
Binary files /dev/null and b/docs/readthedocs/_static/figures/uml/WeatherCoordinateSourceClassDiagram.png differ
diff --git a/docs/readthedocs/conf.py b/docs/readthedocs/conf.py
index 08685db9d..cdf07d375 100644
--- a/docs/readthedocs/conf.py
+++ b/docs/readthedocs/conf.py
@@ -18,12 +18,12 @@
# -- Project information -----------------------------------------------------
project = 'PowerSystemDataModel'
-copyright = u'2020. TU Dortmund University, Institute of Energy Systems, Energy Efficiency and Energy Economics, Research group Distribution grid planning and operation '
-author = 'Johannes Hiry, Debopama Sen Sarma, Chris Kittl'
+copyright = u'2023. TU Dortmund University, Institute of Energy Systems, Energy Efficiency and Energy Economics, Research group Distribution grid planning and operation '
+author = 'Institute of Energy Systems, Energy Efficiency and Energy Economics'
# The full version, including alpha/beta/rc tags
-version = '1.0'
-release = '1.0.1-SNAPSHOT'
+version = '3.0'
+release = '3.0.0'
pygments_style = 'tango'
add_function_parentheses = True
@@ -35,12 +35,12 @@
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
- 'recommonmark',
- 'sphinx.ext.autosectionlabel'
+ 'sphinx.ext.intersphinx',
+ 'myst_parser'
]
-# Prefix all autogenerated labels wit the document to get unique labels (e.g. `index:Hello`)
-autosectionlabel_prefix_document = True
+myst_enable_extensions = ["dollarmath", "amsmath"]
+myst_heading_anchors = 4
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
@@ -49,7 +49,8 @@
# directories to ignore when looking for source files.
# This pattern also affects html_static_path and html_extra_path.
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store', 'venv']
-
+exclude_trees = ['.build']
+source_suffix = ['.rst', '.md']
source_encoding = 'utf-8-sig'
# -- Options for HTML output -------------------------------------------------
diff --git a/docs/readthedocs/models/ValidationUtils.rst b/docs/readthedocs/io/ValidationUtils.md
similarity index 66%
rename from docs/readthedocs/models/ValidationUtils.rst
rename to docs/readthedocs/io/ValidationUtils.md
index e1c46094e..d0c38d9e6 100644
--- a/docs/readthedocs/models/ValidationUtils.rst
+++ b/docs/readthedocs/io/ValidationUtils.md
@@ -1,32 +1,26 @@
-****************
-Validation Utils
-****************
+# Validation Utils
This page gives an overview about the ValidationUtils in the *PowerSystemDataModel*.
-What are the ValidationUtils?
-=============================
+## What are the ValidationUtils?
The methods in ValidationUtils and subclasses can be used to check that objects are valid, meaning their parameters have valid values and they are correctly connected.
-What is checked?
-================
+## What is checked?
- The check methods include checks that assigned values are valid, e.g. lines are not allowed to have negative lengths or the rated power factor of any unit must be between 0 and 1.
- Furthermore, several connections are checked, e.g. that lines only connect nodes of the same voltage level or that the voltage levels indicated for the transformer sides match the voltage levels of the nodes they are connected to.
-How does it work?
-=================
-- The method :code:`ValidationUtils.check(Object)` is the only method that should be called by the user.
+## How does it work?
+- The method `ValidationUtils.check(Object)` is the only method that should be called by the user.
- This check method identifies the object class and forwards it to a specific check method for the given object
- The overall structure of the ValidationUtils methods follows a cascading scheme, orientated along the class tree
-- Example: A :code:`LineInput lineInput` should be checked
- 1. :code:`ValidationUtils.check(lineInput)` is called
- 2. :code:`ValidationUtils.check(lineInput)` identifies the class of the object as :code:`AssetInput` and calls :code:`ValidationUtils.checkAsset(lineInput)`
- 3. :code:`ValidationUtils.checkAsset(lineInput)`, if applicable, checks those parameters that all :code:`AssetInput` have in common (e.g. operation time) and further identifies the object, more specifically, as a :code:`ConnectorInput` and calls :code:`ConnectorValidationUtils.check(lineInput)`
- 4. :code:`ConnectorValidationUtils.check(lineInput)`, if applicable, checks those parameters that all :code:`ConnectorInput` have in common and further identifies the object, more specifically, as a :code:`LineInput` and calls :code:`ConnectorValidationUtils.checkLine(lineInput)`
- 5. :code:`ConnectorValidationUtils.checkLine(lineInput)` checks all specific parameters of a :code:`LineInput`
+- Example: A `LineInput lineInput` should be checked
+ 1. `ValidationUtils.check(lineInput)` is called
+ 2. `ValidationUtils.check(lineInput)` identifies the class of the object as `AssetInput` and calls `ValidationUtils.checkAsset(lineInput)`
+ 3. `ValidationUtils.checkAsset(lineInput)`, if applicable, checks those parameters that all `AssetInput` have in common (e.g. operation time) and further identifies the object, more specifically, as a `ConnectorInput` and calls `ConnectorValidationUtils.check(lineInput)`
+ 4. `ConnectorValidationUtils.check(lineInput)`, if applicable, checks those parameters that all `ConnectorInput` have in common and further identifies the object, more specifically, as a `LineInput` and calls `ConnectorValidationUtils.checkLine(lineInput)`
+ 5. `ConnectorValidationUtils.checkLine(lineInput)` checks all specific parameters of a `LineInput`
- ValidationUtils furthermore contains several utils methods used in the subclasses
-Which objects are checked?
-==========================
+## Which objects are checked?
The ValidationUtils include validation checks for...
- NodeValidationUtils
@@ -80,8 +74,7 @@ The ValidationUtils include validation checks for...
- RawGridElements
- SystemParticipants
-What should be considered?
-==========================
+## What should be considered?
- Due to many checks with if-conditions, the usage of the ValidationUtils for many objects might be runtime relevant.
- The check for a GridContainer includes the interplay of the contained entities as well as the checks of all contained entities.
- If new classes are introduced to the *PowerSystemDataModel*, make sure to follow the forwarding structure of the ValidationUtils methods when writing the check methods!
diff --git a/docs/readthedocs/io/basiciousage.md b/docs/readthedocs/io/basiciousage.md
new file mode 100644
index 000000000..64ce498df
--- /dev/null
+++ b/docs/readthedocs/io/basiciousage.md
@@ -0,0 +1,40 @@
+# I/O
+
+The PowerSystemDataModel library additionally offers I/O-capabilities.
+In the long run, it is our aim to provide many different source and sink technologies.
+Therefore, the I/O-package is structured as highly modular.
+
+```{toctree}
+---
+maxdepth: 2
+---
+csvfiles
+sql
+influxdb
+ValidationUtils.md
+```
+
+## Data sink structure
+
+[](../_static/figures/uml/DataSinkClassDiagram.png)
+
+## Data source structure
+
+The sources are divided in three blocks:
+1. InputEntities and ResultEntities
+2. TimeSeries related sources
+3. Weather and Coordinate sources
+
+[](../_static/figures/uml/EntitySourceClassDiagram.png)
+
+[](../_static/figures/uml/TimeSeriesSourceClassDiagram.png)
+
+[](../_static/figures/uml/WeatherCoordinateSourceClassDiagram.png)
+
+The function to read the sources are implemented in the DataSource classes.
+
+[](../_static/figures/uml/FunctionalDataSourceClassDiagram.png)
+
+## Data deployment
+
+[](../_static/figures/uml/InputDataDeployment.png)
diff --git a/docs/readthedocs/io/basiciousage.rst b/docs/readthedocs/io/basiciousage.rst
deleted file mode 100644
index cf2e3a915..000000000
--- a/docs/readthedocs/io/basiciousage.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-###
-I/O
-###
-The PowerSystemDataModel library additionally offers I/O-capabilities.
-In the long run, it is our aim to provide many different source and sink technologies.
-Therefore, the I/O-package is structured as highly modular.
-
-.. toctree::
- :maxdepth: 2
-
- influxdb
- csvfiles
-
-
-
-Data sink structure
-===================
-.. figure:: ../_static/figures/uml/DataSinkClassDiagram.png
- :align: center
- :width: 650
- :alt: Class diagram of data sink classes
-
-
-Data deployment
-===============
-.. figure:: ../_static/figures/uml/InputDataDeployment.png
- :align: center
- :width: 650
- :alt: Diagram of input data deployment
diff --git a/docs/readthedocs/io/csvfiles.md b/docs/readthedocs/io/csvfiles.md
new file mode 100644
index 000000000..e022918ad
--- /dev/null
+++ b/docs/readthedocs/io/csvfiles.md
@@ -0,0 +1,212 @@
+# CSV files
+
+## Naming of files
+
+A naming strategy provides a mapping between model classes and the human readable names of those entities to be used
+within e.g. the data sinks, in which the serialized representation of several objects of this class can be found.
+Currently we offer two different, pre-defined naming strategies, which you might extend to fit your needs:
+
+1. **EntityPersistenceNamingStrategy**:
+ A basic naming strategy that is able to add prefix and suffix to the names of the entities. A flat folder structure
+ is considered. For more details see [Default naming strategy](#default-naming-strategy).
+2. **HierarchicFileNamingStrategy**:
+ An extended version of the EntityPersistenceNamingStrategy. Additionally, the [Default directory hierarchy](#default-directory-hierarchy) is taken
+ into account. Please note, that this directory hierarchy is only meant to be used in conjunction with input models.
+
+However, you can control the behaviour of serialization and de-serialization of models by injecting the desired naming
+strategy you like into `CsvDataSource` and `CsvFileSink`.
+
+## Default naming strategy
+
+There is a default mapping from model class to naming of entities in the case you would like to use csv files for
+(de-)serialization of models.
+You may extend / alter the naming with pre- or suffix by calling `new EntityPersistenceNamingStrategy("prefix","suffix")`.
+
+### Input
+
+| Model | File Name |
+|:----------------------------------|:------------------------------------------------------------------------------------------|
+| operator | *prefix_* operator_input *_suffix* |
+| node | *prefix_* node_input *_suffix* |
+| line | *prefix_* line_input *_suffix*
*prefix_* line_type_input *_suffix* |
+| switch | *prefix_* switch_input *_suffix* |
+| two winding transformer | *prefix_* transformer2w_input *_suffix*
*prefix_* transformer2w_type_input *_suffix* |
+| three winding transformer | *prefix_* transformer3w_input *_suffix*
*prefix_* transformer3w_type_input *_suffix* |
+| measurement unit | *prefix_* measurement_unit_input *_suffix* |
+| biomass plant | *prefix_* bm_input *_suffix*
*prefix_* bm_type_input *_suffix* |
+| combined heat and power plant | *prefix_* chp_input *_suffix*
*prefix_* chp_type_input *_suffix* |
+| electric vehicle | *prefix_* ev_input *_suffix*
*prefix_* ev_type_input *_suffix* |
+| electric vehicle charging station | *prefix_* evcs_input *_suffix* |
+| fixed feed in facility | *prefix_* fixed_feed_in_input *_suffix* |
+| heat pump | *prefix_* hp_input *_suffix*
*prefix_* hp_type_input *_suffix* |
+| load | *prefix_* load_input *_suffix* |
+| photovoltaic power plant | *prefix_* pc_input *_suffix* |
+| electrical energy storage | *prefix_* storage_input *_suffix*
*prefix_* storage_type_input *_suffix* |
+| wind energy converter | *prefix_* wec_input *_suffix*
*prefix_* wec_type_input *_suffix* |
+| schematic node graphic | *prefix_* node_graphic_input *_suffix* |
+| schematic line graphic | *prefix_* line_graphic_input *_suffix* |
+
+
+### Time Series
+
+| Model | File Name |
+|:-----------------------|:------------------------------------------|
+| individual time series | *prefix_* its *_columnScheme_UUID_suffix* |
+| load profile input | *prefix_* rts *_profileKey_UUID_suffix* |
+
+
+Let's spend a few more words on the individual time series:
+Those files are meant to carry different types of content - one might give information about wholesale market prices,
+the other is a record of power values provided by a real system.
+To be able to understand, what's inside of the file, the *columnScheme* part of the file name gives insight of it's
+content.
+The following keys are supported until now:
+
+| Key | Information and supported head line |
+|:--------|:---------------------------------------------------------------------------------------------------------------------------------------------------------|
+| c | An energy price (e.g. in €/MWh; c stands for charge).
Permissible head line: ``uuid,time,price`` |
+| p | Active power
Permissible head line: ``uuid,time,p`` |
+| pq | Active and reactive power
Permissible head line: ``uuid,time,p,q`` |
+| h | Heat power demand
Permissible head line: ``uuid,time,h`` |
+| ph | Active and heat power
Permissible head line: ``uuid,time,p,h`` |
+| pqh | Active, reactive and heat power
Permissible head line: ``uuid,time,p,q,h`` |
+| weather | Weather information
Permissible head line: ``uuid,time,coordinate,direct_irradiation,diffuse_irradiation,temperature,wind_velocity,wind_direction`` |
+
+
+As the ``uuid`` and ``time`` field are mandatory, they are not mentioned explicitly, here.
+
+### Results
+
+
+| Model | File Name |
+|:----------------------------------|:--------------------------------------------|
+| node | *prefix_* node_res *_suffix* |
+| line | *prefix_* line_res *_suffix* |
+| switch | *prefix_* switch_res *_suffix* |
+| two winding transformer | *prefix_* transformer2w_res *_suffix* |
+| three winding transformer | *prefix_* transformer3w_res *_suffix* |
+| biomass plant | *prefix_* bm_res *_suffix* |
+| combined heat and power plant | *prefix_* chp_res *_suffix* |
+| electric vehicle | *prefix_* ev_res *_suffix* |
+| electric vehicle charging station | *prefix_* evcs_res\*_suffix* |
+| fixed feed in | *prefix_* fixed_feed_in_res *_suffix* |
+| heat pump | *prefix_* hp_res *_suffix* |
+| load | *prefix_* load_res *_suffix* |
+| photovoltaic power plant | *prefix_* pv_res *_suffix* |
+| storage | *prefix_* storage_res *_suffix* |
+| wind energy converter | *prefix_* wec_res *_suffix* |
+| thermal house model | *prefix_* thermal_house_res *_suffix* |
+| cylindrical thermal storage | *prefix_* cylindrical_storage_res *_suffix* |
+
+
+## Default directory hierarchy
+
+Although there is no fixed structure of files mandatory, there is something, we consider to be a good idea of
+structuring things.
+You may either ship your csv files directly in this structure or compress everything in a .tar.gz file.
+However, following this form, we are able to provide you some helpful tools in obtaining and saving your models a bit
+easier.
+
+
+Default directory hierarchy for input classes
+
+
+Default directory hierarchy for result classes
+
+The italic parts are optional and the others are mandatory.
+As you see, this still is a pretty flexible approach, as you only need to provide, what you really need.
+However, note that this hierarchy is only meant to be used in conjunction with input models, yet.
+
+The class `DefaultInputHierarchy` offers some helpful methods to validate and create a default input file
+hierarchy.
+
+## De-serialization (loading models)
+
+Having an instance of [Grid Container](/models/input/grid/gridcontainer) is most of the time the target whenever you load your
+grid. It consists of the three main blocks:
+
+1. [Raw grid elements](/models/input/grid/gridcontainer)
+2. [System participants](/models/input/grid/gridcontainer)
+3. [Graphics](/models/input/grid/gridcontainer)
+
+Those blocks are also reflected in the structure of data source interface definitions.
+There is one source for each of the containers, respectively.
+
+As a full data set has references among the models (e.g. a line model points to its' nodes it connects), there is a
+hierarchical structure, in which models have to be loaded.
+Therefore, the different sources have also references among themselves.
+An application example to load an *exampleGrid* from csv files located in `./exampleGrid` could look like this:
+
+
+``` java
+ /* Parameterization */
+ String gridName = "exampleGrid";
+ String csvSep = ",";
+ String folderPath = "./exampleGrid";
+ EntityPersistenceNamingStrategy namingStrategy = new EntityPersistenceNamingStrategy(); // Default naming strategy
+
+ /* Instantiating sources */
+ TypeSource typeSource = new CsvTypeSource(csvSep, folderPath, namingStrategy);
+ RawGridSource rawGridSource = new CsvRawGridSource(csvSep, folderPath, namingStrategy, typeSource);
+ ThermalSource thermalSource = new CsvThermalSource(csvSep, folderPath, namingStrategy, typeSource);
+ SystemParticipantSource systemParticipantSource = new CsvSystemParticipantSource(
+ csvSep,
+ folderPath,
+ namingStrategy,
+ typeSource,
+ thermalSource,
+ rawGridSource
+ );
+ GraphicSource graphicsSource = new CsvGraphicSource(
+ csvSep,
+ folderPath,
+ namingStrategy,
+ typeSource,
+ rawGridSource
+ );
+
+ /* Loading models */
+ RawGridElements rawGridElements = rawGridSource.getGridData().orElseThrow(
+ () -> new SourceException("Error during reading of raw grid data."));
+ SystemParticipants systemParticipants = systemParticipantSource.getSystemParticipants().orElseThrow(
+ () -> new SourceException("Error during reading of system participant data."));
+ GraphicElements graphicElements = graphicsSource.getGraphicElements().orElseThrow(
+ () -> new SourceException("Error during reading of graphic elements."));
+ JointGridContainer fullGrid = new JointGridContainer(
+ gridName,
+ rawGridElements,
+ systemParticipants,
+ graphicElements
+ );
+```
+
+As observable from the code, it doesn't play a role, where the different parts come from.
+It is also a valid solution, to receive types from file, but participants and raw grid elements from a data base.
+Only prerequisite is an implementation of the different interfaces for the desired data source.
+
+## Serialization (writing models)
+
+Serializing models is a bit easier:
+
+``` java
+ /* Parameterization */
+ String csvSep = ",";
+ String folderPath = "./exampleGrid";
+ EntityPersistenceNamingStrategy namingStrategy = new EntityPersistenceNamingStrategy();
+ boolean initEmptyFiles = false;
+
+ /* Instantiating the sink */
+ CsvFileSink sink = new CsvFileSink(folderPath, namingStrategy, initEmptyFiles, csvSep);
+ sink.persistJointGridContainer(grid);
+```
+
+The sink takes a collection of model suitable for serialization and handles the rest (e.g. unboxing of nested models)
+on its own.
+But caveat: As the (csv) writers are implemented in a concurrent, non-blocking way, duplicates of nested models could
+occur.
+
+## Compression and extraction of files
+
+We consider either regular directories or compressed [tarball archives](https://en.wikipedia.org/wiki/Tar_(computing))
+(`*.tar.gz`) as source of input files.
+The class `TarballUtils` offers some helpful functions to compress or extract input data files for easier shipping.
\ No newline at end of file
diff --git a/docs/readthedocs/io/csvfiles.rst b/docs/readthedocs/io/csvfiles.rst
deleted file mode 100644
index 35ab4b8c8..000000000
--- a/docs/readthedocs/io/csvfiles.rst
+++ /dev/null
@@ -1,292 +0,0 @@
-*********
-csv files
-*********
-
-Naming of files
-===============
-A naming strategy provides a mapping between model classes and the human readable names of those entities to be used
-within e.g. the data sinks, in which the serialized representation of several objects of this class can be found.
-Currently we offer two different, pre-defined naming strategies, which you might extend to fit your needs:
-
-1. **EntityPersistenceNamingStrategy**:
- A basic naming strategy that is able to add prefix and suffix to the names of the entities. A flat folder structure
- is considered. For more details see `Default naming strategy`_.
-2. **HierarchicFileNamingStrategy**:
- An extended version of the EntityPersistenceNamingStrategy. Additionally, the `Default directory hierarchy`_ is taken
- into account. Please note, that this directory hierarchy is only meant to be used in conjunction with input models.
-
-However, you can control the behaviour of serialization and de-serialization of models by injecting the desired naming
-strategy you like into :code:`CsvDataSource` and :code:`CsvFileSink`.
-
-Default naming strategy
-=======================
-There is a default mapping from model class to naming of entities in the case you would like to use csv files for
-(de-)serialization of models.
-You may extend / alter the naming with pre- or suffix by calling :code:`new EntityPersistenceNamingStrategy("prefix","suffix")`.
-
-Input
------
-
-+--------------------------------------------------------+--------------------------------------------------+
-| Model | File Name |
-+========================================================+==================================================+
-| :ref:`operator` | *prefix_*\ operator_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`node` | *prefix_*\ node_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`line` | | *prefix_*\ line_input\ *_suffix* |
-| | | *prefix_*\ line_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`switch` | *prefix_*\ switch_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`two winding transformer` | | *prefix_*\ transformer2w_input\ *_suffix* |
-| | | *prefix_*\ transformer2w_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`three winding transformer` | | *prefix_*\ transformer3w_input\ *_suffix* |
-| | | *prefix_*\ transformer3w_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`measurement unit` | *prefix_*\ measurement_unit_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`biomass plant` | | *prefix_*\ bm_input\ *_suffix* |
-| | | *prefix_*\ bm_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`combined heat and power plant` | | *prefix_*\ chp_input\ *_suffix* |
-| | | *prefix_*\ chp_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`electric vehicle` | | *prefix_*\ ev_input\ *_suffix* |
-| | | *prefix_*\ ev_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`electric vehicle charging station` | *prefix_*\ evcs_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`fixed feed in facility` | *prefix_*\ fixed_feed_in_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`heat pump` | | *prefix_*\ hp_input\ *_suffix* |
-| | | *prefix_*\ hp_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`load` | *prefix_*\ load_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`photovoltaic power plant` | *prefix_*\ pc_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`electrical energy storage` | | *prefix_*\ storage_input\ *_suffix* |
-| | | *prefix_*\ storage_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`wind energy converter` | | *prefix_*\ wec_input\ *_suffix* |
-| | | *prefix_*\ wec_type_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`schematic node graphic` | *prefix_*\ node_graphic_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-| :ref:`schematic line graphic` | *prefix_*\ line_graphic_input\ *_suffix* |
-+--------------------------------------------------------+--------------------------------------------------+
-
-Time Series
------------
-
-+-------------------------------------------------------+---------------------------------------------+
-| Model | File Name |
-+=======================================================+=============================================+
-| :ref:`individual time series` | *prefix_*\ its\ *_columnScheme_UUID_suffix* |
-+-------------------------------------------------------+---------------------------------------------+
-| :ref:`load profile input` | *prefix_*\ rts\ *_profileKey_UUID_suffix* |
-+-------------------------------------------------------+---------------------------------------------+
-
-Let's spend a few more words on the individual time series:
-Those files are meant to carry different types of content - one might give information about wholesale market prices,
-the other is a record of power values provided by a real system.
-To be able to understand, what's inside of the file, the *columnScheme* part of the file name gives insight of it's
-content.
-The following keys are supported until now:
-
-+---------+----------------------------------------------------------------------------------------------------------------+
-| Key | Information and supported head line |
-+=========+================================================================================================================+
-| c | | An energy price (e.g. in €/MWh; c stands for charge). |
-| | | Permissible head line: ``uuid,time,price`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| p | | Active power |
-| | | Permissible head line: ``uuid,time,p`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| pq | | Active and reactive power |
-| | | Permissible head line: ``uuid,time,p,q`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| h | | Heat power demand |
-| | | Permissible head line: ``uuid,time,h`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| ph | | Active and heat power |
-| | | Permissible head line: ``uuid,time,p,h`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| pqh | | Active, reactive and heat power |
-| | | Permissible head line: ``uuid,time,p,q,h`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-| weather | | Weather information |
-| | | Permissible head line: |
-| | | ``uuid,time,coordinate,direct_irradiation,diffuse_irradiation,temperature,wind_velocity,wind_direction`` |
-+---------+----------------------------------------------------------------------------------------------------------------+
-
-As the ``uuid`` and ``time`` field are mandatory, they are not mentioned explicitly, here.
-
-Results
--------
-
-+---------------------------------------------------------------+-----------------------------------------------+
-| Model | File Name |
-+===============================================================+===============================================+
-| :ref:`node` | *prefix_*\ node_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`line` | *prefix_*\ line_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`switch` | *prefix_*\ switch_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`two winding transformer` | *prefix_*\ transformer2w_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`three winding transformer` | *prefix_*\ transformer3w_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`biomass plant` | *prefix_*\ bm_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`combined heat and power plant` | *prefix_*\ chp_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`electric vehicle` | *prefix_*\ ev_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`electric vehicle charging station` | *prefix_*\ evcs_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`fixed feed in` | *prefix_*\ fixed_feed_in_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`heat pump` | *prefix_*\ hp_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`load` | *prefix_*\ load_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`photovoltaic power plant` | *prefix_*\ pv_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`storage` | *prefix_*\ storage_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`wind energy converter` | *prefix_*\ wec_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`thermal house model` | *prefix_*\ thermal_house_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-| :ref:`cylindrical thermal storage` | *prefix_*\ cylindrical_storage_res\ *_suffix* |
-+---------------------------------------------------------------+-----------------------------------------------+
-
-Default directory hierarchy
-===========================
-Although there is no fixed structure of files mandatory, there is something, we consider to be a good idea of
-structuring things.
-You may either ship your csv files directly in this structure or compress everything in a .tar.gz file.
-However, following this form, we are able to provide you some helpful tools in obtaining and saving your models a bit
-easier.
-
-.. figure:: ../_static/figures/uml/DefaultInputDirectoryHierarchy.png
- :align: center
- :alt: Default directory hierarchy for input classes
- :width: 650
-
- Default directory hierarchy for input classes
-
-.. figure:: ../_static/figures/uml/DefaultResultDirectoryHierarchy.png
- :align: center
- :alt: Default directory hierarchy for result classes
- :width: 650
-
- Default directory hierarchy for result classes
-
-The italic parts are optional and the others are mandatory.
-As you see, this still is a pretty flexible approach, as you only need to provide, what you really need.
-However, note that this hierarchy is only meant to be used in conjunction with input models, yet.
-
-The class :code:`DefaultInputHierarchy` offers some helpful methods to validate and create a default input file
-hierarchy.
-
-De-serialization (loading models)
-=================================
-Having an instance of :ref:`Grid Container` is most of the time the target whenever you load your
-grid. It consists of the three main blocks:
-
- 1. :ref:`Raw grid elements`
- 2. :ref:`System participants`
- 3. :ref:`Graphics`
-
-Those blocks are also reflected in the structure of data source interface definitions.
-There is one source for each of the containers, respectively.
-
-.. figure:: ../_static/figures/uml/DataSourceClassDiagram.png
- :align: center
- :alt: Class diagram of data sources
- :width: 650
-
- Class diagram of data sources
-
-As a full data set has references among the models (e.g. a line model points to its' nodes it connects), there is a
-hierarchical structure, in which models have to be loaded.
-Therefore, the different sources have also references among themselves.
-An application example to load an *exampleGrid* from csv files located in :code:`./exampleGrid` could look like this:
-
-.. code-block:: java
-
- /* Parameterization */
- String gridName = "exampleGrid";
- String csvSep = ",";
- String folderPath = "./exampleGrid";
- EntityPersistenceNamingStrategy namingStrategy = new EntityPersistenceNamingStrategy(); // Default naming strategy
-
- /* Instantiating sources */
- TypeSource typeSource = new CsvTypeSource(csvSep, folderPath, namingStrategy);
- RawGridSource rawGridSource = new CsvRawGridSource(csvSep, folderPath, namingStrategy, typeSource);
- ThermalSource thermalSource = new CsvThermalSource(csvSep, folderPath, namingStrategy, typeSource);
- SystemParticipantSource systemParticipantSource = new CsvSystemParticipantSource(
- csvSep,
- folderPath,
- namingStrategy,
- typeSource,
- thermalSource,
- rawGridSource
- );
- GraphicSource graphicsSource = new CsvGraphicSource(
- csvSep,
- folderPath,
- namingStrategy,
- typeSource,
- rawGridSource
- );
-
- /* Loading models */
- RawGridElements rawGridElements = rawGridSource.getGridData().orElseThrow(
- () -> new SourceException("Error during reading of raw grid data."));
- SystemParticipants systemParticipants = systemParticipantSource.getSystemParticipants().orElseThrow(
- () -> new SourceException("Error during reading of system participant data."));
- GraphicElements graphicElements = graphicsSource.getGraphicElements().orElseThrow(
- () -> new SourceException("Error during reading of graphic elements."));
- JointGridContainer fullGrid = new JointGridContainer(
- gridName,
- rawGridElements,
- systemParticipants,
- graphicElements
- );
-
-As observable from the code, it doesn't play a role, where the different parts come from.
-It is also a valid solution, to receive types from file, but participants and raw grid elements from a data base.
-Only prerequisite is an implementation of the different interfaces for the desired data source.
-
-Serialization (writing models)
-==============================
-Serializing models is a bit easier:
-
-.. code-block:: java
-
- /* Parameterization */
- String csvSep = ",";
- String folderPath = "./exampleGrid";
- EntityPersistenceNamingStrategy namingStrategy = new EntityPersistenceNamingStrategy();
- boolean initEmptyFiles = false;
-
- /* Instantiating the sink */
- CsvFileSink sink = new CsvFileSink(folderPath, namingStrategy, initEmptyFiles, csvSep);
- sink.persistJointGridContainer(grid);
-
-The sink takes a collection of model suitable for serialization and handles the rest (e.g. unboxing of nested models)
-on its own.
-But caveat: As the (csv) writers are implemented in a concurrent, non-blocking way, duplicates of nested models could
-occur.
-
-Compression and extraction of files
-===================================
-We consider either regular directories or compressed `tarball archives `_
-(:code:`*.tar.gz`) as source of input files.
-The class :code:`TarballUtils` offers some helpful functions to compress or extract input data files for easier shipping.
\ No newline at end of file
diff --git a/docs/readthedocs/io/sql.md b/docs/readthedocs/io/sql.md
new file mode 100644
index 000000000..71edba1a3
--- /dev/null
+++ b/docs/readthedocs/io/sql.md
@@ -0,0 +1,8 @@
+# SQL
+
+
+## Id Coordinate Source
+The sql implementation of id coordinate source uses [PostgreSql](https://www.postgresql.org/) with the
+addon [PostGis](https://postgis.net/). `PostGis` is used to improve the querying of geographical data.
+The `Coordinate` attribute is stored as a [Geography](http://postgis.net/workshops/postgis-intro/geography.html) with
+the type [Point](https://postgis.net/docs/ST_Point.html) and the default SRID 4326.
diff --git a/docs/readthedocs/models/input/additionaldata/idcoordinatesource.md b/docs/readthedocs/models/input/additionaldata/idcoordinatesource.md
new file mode 100644
index 000000000..665490477
--- /dev/null
+++ b/docs/readthedocs/models/input/additionaldata/idcoordinatesource.md
@@ -0,0 +1,92 @@
+# IdCoordinateSource
+An id coordinate source provides a mapping between ids of a coordinate and the actual coordinates
+latitude and longitude values. The id coordinate source itself is an interface that provides some
+methods to get coordinates, ids of coordinates or the distance between a given coordinate and other
+coordinates.
+
+
+## Information
+
+| Attribute | Remarks |
+|:-------------|:---------------------------------------------------------------|
+| `Id` | An integer value for identifying the coordinate. |
+| `Coordiante` | Geographical information presented as `Lat/long` of a `Point`. |
+
+
+
+## Known implementations:
+The following implementations are currently known:
+
+- [Csv Id Coordinate Source](/io/csvfiles)
+- [Sql Id Coordinate Source](/io/sql)
+
+
+## Method for coordinates:
+The IdCoordinateSource contains method for returning coordinates for given ids.
+
+``` java
+ Optional getCoordinate(int id)
+ Collection getCoordinates(int... ids)
+ Collection getAllCoordinates()
+```
+
+1. This method is used to return the coordinate of a given id. If no coordinate is found for
+the given id, an empty optional is returned.
+
+2. This method is used to return the coordinates of a given set of ids. The method will only return
+coordinates for existing ids.
+
+3. This method is used to return all available coordinates.
+
+
+## Method for ids:
+The IdCoordinateSource contains a method for retrieving the id of a given coordinate.
+
+``` java
+ Optional getId(Point coordinate)
+```
+
+This method is used to return the id of a given coordinate. If no id is found for the given
+coordinate, an empty optional is returned.
+
+
+## Method for retrieving near coordinates:
+The IdCoordinateSource also contains methods for retrieving coordinates/points that are near a given coordinate.
+All implementations of these methods in this project will use the method ``restrictToBoundingBox`` for finding and
+returning four corner points.
+
+``` java
+ List getNearestCoordinates(Point coordinatem int n)
+ List getClosestCoordinates(Point coordinate, int n, ComparableQuantity distance)
+ List calculateCoordinateDistances(Point coordinate, int n, Collection coordinates)
+```
+
+1. This method will return the nearest n coordinates for a given coordinate. The method works by having a default radius
+that is increased with every iteration until n coordinates are found.
+
+2. This method will return the closest n coordinates for a given coordinate. Unlike the first method, this method has a
+defined radius, that won't be increased. Therefor this method can only consider the coordinates inside the bounding box
+around this radius.
+
+3. This method is used to calculate the distances to a set of give coordinates. After the calculation
+the method will return the closest n coordinates. If the number of distances is less than n, this method will
+return less than n coordinates.
+
+
+## Finding and returning the closest corner coordinates:
+In most cases we need four corner coordinates for our given coordinate. Therefor the
+IdCoordinateSource contains a method that will use the calculated distances to find the closest
+corner coordinates for the given coordinate.
+
+``` java
+ List restrictToBoundingBox(
+ Point coordinate,
+ Collection distances,
+ int numberOfPoints
+ )
+```
+
+For a given set of coordinates, the closest four corner coordinates plus more close points if n > 4
+are returned. If n < 4 the method will return the closest n corner coordinates. If the set of
+coordinates contains a coordinate that matches the given coordinate, only this one coordinate is
+returned. If n > number of coordinates in the set, all coordinates are returned.
\ No newline at end of file
diff --git a/docs/readthedocs/models/input/additionaldata/timeseries.md b/docs/readthedocs/models/input/additionaldata/timeseries.md
new file mode 100644
index 000000000..9590a8404
--- /dev/null
+++ b/docs/readthedocs/models/input/additionaldata/timeseries.md
@@ -0,0 +1,30 @@
+# Time Series
+Time series are meant to represent a timely ordered series of values.
+Those can either be electrical or non-electrical depending on what one may need for power system simulations.
+Our time series models are divided into two subtypes:
+
+## Individual Time Series
+Each time instance in this time series has its own value (random duplicates may occur obviously).
+They are only applicable for the time frame that is defined by the content of the time series.
+
+## Repetitive Time Series
+Those time series do have repetitive values, e.g. each day or at any other period.
+Therefore, they can be applied to any time frame, as the mapping from time instant to value is made by information
+reduction.
+In addition to actual data, a mapping function has to be known.
+
+## Available Classes
+To be as flexible, as possible, the actual content of the time series is given as children of the `Value` class.
+The following different values are available:
+
+| Value Class | Purpose |
+|:-----------------------|:--------------------------------------------------------------------------------------------------------------|
+| `PValue` | Electrical active power |
+| `SValue` | Electrical active and reactive power |
+| `HeatAndPValue` | Combination of thermal power (e.g. in kW)
and electrical active power (e.g. in kW) |
+| `HeatAndSValue` | Combination of thermal power (e.g. in kW)
and electrical active and reactive power (e.g. in kW and kVAr) |
+| `EnergyPriceValue` | Wholesale market price (e.g. in € / MWh) |
+| `SolarIrradianceValue` | Combination of diffuse and direct solar irradiance |
+| `TemperatureValue` | Temperature information |
+| `WindValue` | Combination of wind direction and wind velocity |
+| `WeatherValue` | Combination of irradiance, temperature and wind information |
diff --git a/docs/readthedocs/models/input/grid/gridcontainer.md b/docs/readthedocs/models/input/grid/gridcontainer.md
new file mode 100644
index 000000000..e40d20c5c
--- /dev/null
+++ b/docs/readthedocs/models/input/grid/gridcontainer.md
@@ -0,0 +1,92 @@
+# Grid Container
+
+The grid container groups all entities that are able to form a full grid model.
+Two types of grid containers are available:
+
+**JointGridContainer**
+This one is able to hold a grid model spanning several voltage levels.
+On instantiation, a sub grid topology graph is built.
+This graph holds `SubGridContainers` as vertices and transformer models as edges.
+Thereby, you are able to discover the topology of galvanically separated sub grids and access those sub models
+directly.
+
+and
+
+**SubGridContainer**
+This one is meant to hold all models, that form a galvanically separated sub grid.
+In contrast to the `JointGridContainer` it only covers one voltage level and therefore has an additional field
+for the predominant voltage level apparent in the container.
+Why predominant?
+As of convention, the `SubGridContainers` hold also reference to the transformers leading to higher sub grids
+and their higher voltage coupling point.
+
+
+
+Let's shed a more detailed light on the boundaries of a sub grid as of our definition.
+This especially is important, if the switchgear of the transformer is modeled in detail.
+We defined, that all nodes in upstream direction of the transformer, that are connected by switches *only* (therefore
+are within the switchgear) are counted towards the inferior sub grid structure (here "2"), although they belong to a
+different voltage level.
+This decision is taken, because we assume, that the interest to operate on the given switchgear will most likely be
+placed in the inferior grid structure.
+
+The "real" coupling node A is not comprised in the sub grids node collection, but obviously has reference through the
+switch between nodes A and B.
+
+A synoptic overview of both classes' attributes is given here:
+
+## Attributes, Units and Remarks
+
+| Attribute | Unit | Remarks |
+|:------------------------|:-----|:--------------------------------------------------|
+| gridName | -- | Human readable identifier |
+| rawGrid | -- | see below |
+| systemParticipants | -- | see below |
+| graphics | -- | see below |
+| subGridTopologyGraph | -- | topology of sub grids - only `JointGridContainer` |
+| predominantVoltageLevel | -- | main voltage level - only `SubGridContainer` |
+| subnet | -- | sub grid number - only `SubGridContainer` |
+
+
+### RawGridElements
+This sub container simply holds:
+
+* [nodes](/models/input/grid/node)
+* [lines](/models/input/grid/line)
+* [switches](/models/input/grid/switch)
+* [two winding transformers](/models/input/grid/transformer2w)
+* [three winding transformers](/models/input/grid/transformer3w)
+* [measurement units](/models/input/grid/measurementunit)
+
+
+### SystemParticipants
+This sub container simply holds:
+
+* [biomass plant](/models/input/participant/bm)
+* [combined heat and power plant](/models/input/participant/chp)
+- [electric vehicles](/models/input/participant/ev)
+- [electric vehicle charging stations](/models/input/participant/evcs)
+- [fixed feed in facilities](/models/input/participant/fixedfeedin)
+- [heat pumps](/models/input/participant/hp)
+- [loads](/models/input/participant/load)
+- [photovoltaic power plants](/models/input/participant/pv)
+- [electrical energy storages](/models/input/participant/storage)
+- [wind energy converters](/models/input/participant/wec)
+
+and the needed nested thermal models.
+
+
+### Graphics
+This sub container simply holds:
+
+* [schematic node graphics](/models/input/grid/nodegraphic)
+* [schematic line graphics](/models/input/grid/linegraphic)
+
+
+## Container Concept
+
+
+
+## Caveats
+Nothing - at least not known.
+If you found something, please contact us!
\ No newline at end of file
diff --git a/docs/readthedocs/models/input/grid/gridcontainer.rst b/docs/readthedocs/models/input/grid/gridcontainer.rst
deleted file mode 100644
index 85503c08c..000000000
--- a/docs/readthedocs/models/input/grid/gridcontainer.rst
+++ /dev/null
@@ -1,113 +0,0 @@
-.. _grid_container_model:
-
-Grid Container
---------------
-The grid container groups all entities that are able to form a full grid model.
-Two types of grid containers are available:
-
-JointGridContainer
- This one is able to hold a grid model spanning several voltage levels.
- On instantiation, a sub grid topology graph is built.
- This graph holds :code:`SubGridContainers` as vertices and transformer models as edges.
- Thereby, you are able to discover the topology of galvanically separated sub grids and access those sub models
- directly.
-
-and
-
-SubGridContainer
- This one is meant to hold all models, that form a galvanically separated sub grid.
- In contrast to the :code:`JointGridContainer` it only covers one voltage level and therefore has an additional field
- for the predominant voltage level apparent in the container.
- Why predominant?
- As of convention, the :code:`SubGridContainers` hold also reference to the transformers leading to higher sub grids
- and their higher voltage coupling point.
-
- .. figure:: ../../../_static/figures/transformerWithSwitchGear.png
- :align: center
- :alt: Sub grid boundary definition for transformers with upstream switchgear
-
- Let's shed a more detailed light on the boundaries of a sub grid as of our definition.
- This especially is important, if the switchgear of the transformer is modeled in detail.
- We defined, that all nodes in upstream direction of the transformer, that are connected by switches *only* (therefore
- are within the switchgear) are counted towards the inferior sub grid structure (here "2"), although they belong to a
- different voltage level.
- This decision is taken, because we assume, that the interest to operate on the given switchgear will most likely be
- placed in the inferior grid structure.
-
- The "real" coupling node A is not comprised in the sub grids node collection, but obviously has reference through the
- switch between nodes A and B.
-
-A synoptic overview of both classes' attributes is given here:
-
-Attributes, Units and Remarks
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-+-------------------------+------+---------------------------------------------------------+
-| Attribute | Unit | Remarks |
-+=========================+======+=========================================================+
-| gridName | -- | Human readable identifier |
-+-------------------------+------+---------------------------------------------------------+
-| rawGrid | -- | see below |
-+-------------------------+------+---------------------------------------------------------+
-| systemParticipants | -- | see below |
-+-------------------------+------+---------------------------------------------------------+
-| graphics | -- | see below |
-+-------------------------+------+---------------------------------------------------------+
-| subGridTopologyGraph | -- | topology of sub grids - only :code:`JointGridContainer` |
-+-------------------------+------+---------------------------------------------------------+
-| predominantVoltageLevel | -- | main voltage level - only :code:`SubGridContainer` |
-+-------------------------+------+---------------------------------------------------------+
-| subnet | -- | sub grid number - only :code:`SubGridContainer` |
-+-------------------------+------+---------------------------------------------------------+
-
-.. _grid_container_raw_grid_elements:
-
-RawGridElements
-"""""""""""""""
-This sub container simply holds:
-
- * :ref:`nodes`
- * :ref:`lines`
- * :ref:`switches`
- * :ref:`two winding transformers`
- * :ref:`three winding transformers`
- * :ref:`measurement units`
-
-.. _grid_container_system_participants:
-
-SystemParticipants
-""""""""""""""""""
-This sub container simply holds:
-
- * :ref:`biomass plants`
- * :ref:`combined heat and power plants`
- * :ref:`electric vehicles`
- * :ref:`electric vehicle charging stations`
- * :ref:`fixed feed in facilities`
- * :ref:`heat pumps`
- * :ref:`loads`
- * :ref:`photovoltaic power plants`
- * :ref:`electrical energy storages`
- * :ref:`wind energy converters`
-
-and the needed nested thermal models.
-
-.. _grid_container_graphics:
-
-Graphics
-""""""""
-This sub container simply holds:
-
- * :ref:`schematic node graphics`
- * :ref:`schematic line graphics`
-
-Container Concept
-"""""""""""""""""
- .. figure:: ../../../_static/figures/uml/ModelContainerConcept.png
- :align: center
- :width: 650
- :alt: Model container concept
-
-Caveats
-^^^^^^^
-Nothing - at least not known.
-If you found something, please contact us!
\ No newline at end of file
diff --git a/docs/readthedocs/models/input/grid/line.md b/docs/readthedocs/models/input/grid/line.md
new file mode 100644
index 000000000..7c8facdf7
--- /dev/null
+++ b/docs/readthedocs/models/input/grid/line.md
@@ -0,0 +1,102 @@
+# Line
+
+Representation of an AC line.
+
+## Attributes, Units and Remarks
+
+### Type Model
+
+| Attribute | Unit | Remarks |
+|:----------|:--------|:--------------------------------------------|
+| uuid | -- | |
+| id | -- | Human readable identifier |
+| r | Ω / km | Phase resistance per length |
+| x | Ω / km | Phase reactance per length |
+| g | µS / km | Phase-to-ground conductance per length |
+| b | µS / km | Phase-to-ground susceptance per length |
+| iMax | A | Maximum permissible current |
+| vRated | kV | Rated voltage |
+
+
+A list with some standard line types can be found here: `Standard Line Types`_
+
+
+### Entity Model
+
+| Attribute | Unit | Remarks |
+|:------------------|:-----|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| uuid | -- | |
+| id | -- | Human readable identifier |
+| operator | -- | |
+| operationTime | -- | Timely restriction of operation |
+| nodeA | -- | |
+| nodeB | -- | |
+| parallelDevices | -- | overall amount of parallel lines to automatically
construct (e.g. parallelDevices = 2 will build a
total of two lines using the specified parameters) |
+| type | -- | |
+| length | km | |
+| geoPosition | -- | Line string of geographical locations describing the
position of the line |
+| olmCharacteristic | -- | Characteristic of possible overhead line monitoring
Can be given in the form of `olm:{}`.
The pairs are wind velocity in x and permissible
loading in y. |
+
+
+
+## Standard Line Types
+
+Following there are some standard line types with their source. A ``csv file`` containing the types listed below can be found
+`here `_. This file can be used directly
+for any simulation with ``simona``.
+The lines which source is ``simBench`` are from `here `_.
+
+
+### Overhead Lines
+
+Some standard overhead lines.
+
+| uuid | b | g | iMax | id | r | vRated | x | source |
+|:--------------------------------------|--------:|----:|--------:|--------------------:|---------:|-------:|---------:|:---------|
+| 91617ab8-3de2-4fba-be45-a54473ba09a9 | 3.61283 | 0.0 | 1300.0 | LineType_1 | 0.08 | 380.0 | 0.32 | simBench |
+| b3b231ae-a971-4432-80d7-4ce2f2a56a32 | 3.22799 | 0.0 | 1950.0 | LineType_4 | 0.033333 | 380.0 | 0.333333 | simBench |
+| 24595f91-8295-41f8-a3d8-c9418d860d9c | 1.076 | 0.0 | 650.0 | LineType_6 | 0.1 | 380.0 | 1.0 | simBench |
+| f0fc57ec-aa5a-4484-b870-be70a5428cbd | 6.45597 | 0.0 | 3900.0 | LineType_9 | 0.016667 | 380.0 | 0.166667 | simBench |
+| ba70d8e7-b082-49bc-8c45-3c10e1236c3e | 8.60796 | 0.0 | 5200.0 | LineType_10 | 0.0125 | 380.0 | 0.125 | simBench |
+| veee8eeed-62c9-4345-aa5a-3743fe32007d | 12.9119 | 0.0 | 7800.0 | LineType_11 | 0.008333 | 380.0 | 0.083333 | simBench |
+| d2b16935-dcd7-44d2-8623-cec4c703ccdc | 17.2159 | 0.0 | 10400.0 | LineType_12 | 0.00625 | 380.0 | 0.0625 | simBench |
+| a490c96e-6e90-485a-b0d7-adeb81fa09cd | 4.30398 | 0.0 | 2600.0 | LineType_2 | 0.025 | 220.0 | 0.25 | simBench |
+| 5272bcbc-7d0e-4759-85fa-27943fd8d19c | 2.15199 | 0.0 | 1300.0 | LineType_3 | 0.05 | 220.0 | 0.5 | simBench |
+| dd0bac07-de8d-4608-af36-b8ff2819f55a | 7.22566 | 0.0 | 2600.0 | LineType_5 | 0.04 | 220.0 | 0.16 | simBench |
+| 64c1dcb5-57a5-4f35-b2bf-9ae4e6cc4943 | 1.80642 | 0.0 | 650.0 | LineType_7 | 0.16 | 220.0 | 0.64 | simBench |
+| bdc83a85-c796-4bcb-8b79-8988dc2804f8 | 5.41925 | 0.0 | 1950.0 | LineType_8 | 0.053333 | 220.0 | 0.213333 | simBench |
+| 3d75fb6b-f0be-4451-ab4c-7f00c0ebd619 | 2.8274 | 0.0 | 680.0 | Al/St_265/35 | 0.1095 | 110.0 | 0.296 | simBench |
+| f5dcaf44-7a9a-4b85-89ba-5c15c04c5766 | 3.45575 | 0.0 | 105.0 | 15-AL1/3-ST1A 20.0 | 1.8769 | 20.0 | 0.409 | simBench |
+| 9cbf484b-7256-4e7a-9c35-3e1049909aa0 | 3.53429 | 0.0 | 140.0 | 24-AL1/4-ST1A 20.0 | 1.2012 | 20.0 | 0.394 | simBench |
+| 5b542a50-b0c2-4497-ba90-b2b31aafaa0b | 2.87456 | 0.0 | 170.0 | 34-AL1/6-ST1A 20.0 | 0.8342 | 20.0 | 0.382 | simBench |
+| d594cd67-4459-44bc-9594-db710372db71 | 2.98451 | 0.0 | 210.0 | 48-AL1/8-ST1A 20.0 | 0.5939 | 20.0 | 0.372 | simBench |
+| 305e60ad-cfd2-4127-9d83-8d9b21942d93 | 3.04734 | 0.0 | 290.0 | 70-AL1/11-ST1A 20.0 | 0.4132 | 20.0 | 0.36 | simBench |
+
+
+### Cables
+
+Some standard cables.
+
+| uuid | b | g | iMax | id | r | vRated | x | source |
+|:-------------------------------------|--------:|----:|------:|-----------------------------:|-------:|-------:|----------:|:---------|
+| cc59abd4-770b-45d2-98c8-919c91f1ca4b | 58.7478 | 0.0 | 652.0 | 1x630_RM/50 | 0.122 | 110.0 | 0.122522 | simBench |
+| 82ea1b98-2b21-48bd-841a-8d17d8ac20c9 | 59.3761 | 0.0 | 158.0 | NA2XS2Y 1x50 RM/25 12/20 kV | 0.64 | 20.0 | 0.145 | simBench |
+| 4adef9e6-5e40-416d-8bd2-b6768d156c54 | 59.6903 | 0.0 | 220.0 | NA2XS2Y 1x70 RM/25 12/20 kV | 0.443 | 20.0 | 0.132 | simBench |
+| d5c03484-59c2-44d5-a2ee-63a5a0d623b4 | 67.8584 | 0.0 | 252.0 | NA2XS2Y 1x95 RM/25 12/20 kV | 0.313 | 20.0 | 0.132 | simBench |
+| 9c13909d-1dd1-4e2d-980b-55345bdf0fd0 | 72.2566 | 0.0 | 283.0 | NA2XS2Y 1x120 RM/25 12/20 kV | 0.253 | 20.0 | 0.119 | simBench |
+| 36243493-eb31-4e81-bd13-b54ef59c4cbe | 78.5398 | 0.0 | 319.0 | NA2XS2Y 1x150 RM/25 12/20 kV | 0.206 | 20.0 | 0.116 | simBench |
+| 437689f8-366d-4b04-b42d-d7a754db074b | 85.7655 | 0.0 | 362.0 | NA2XS2Y 1x185 RM/25 12/20 kV | 0.161 | 20.0 | 0.117 | simBench |
+| b459115d-d4eb-47d4-b7ec-625339ee0dcc | 95.5044 | 0.0 | 421.0 | NA2XS2Y 1x240 RM/25 12/20 kV | 0.122 | 20.0 | 0.112 | simBench |
+| 9aed5818-c037-4033-8d15-806c62d70b8f | 113.097 | 0.0 | 315.0 | NA2XS2Y 1x150 RM/25 6/10 kV | 0.206 | 10.0 | 0.11 | simBench |
+| 60d37bc7-157a-4c32-b1b5-e74c10d70531 | 127.549 | 0.0 | 358.0 | NA2XS2Y 1x185 RM/25 6/10 kV | 0.161 | 10.0 | 0.11 | simBench |
+| a3ced617-2ffd-4593-b8e9-bcad9a521aab | 143.257 | 0.0 | 416.0 | NA2XS2Y 1x240 RM/25 6/10 kV | 0.122 | 10.0 | 0.105 | simBench |
+| f0484bb6-9d0d-4d13-bfbe-b83783b8352a | 150.796 | 0.0 | 471.0 | NA2XS2Y 1x300 RM/25 6/10 kV | 0.1 | 10.0 | 0.0974 | simBench |
+| 6b223bc3-69e2-4eb8-a2c0-76be1cd2c998 | 169.646 | 0.0 | 535.0 | NA2XS2Y 1x400 RM/25 6/10 kV | 0.078 | 10.0 | 0.0942 | simBench |
+| 65181464-230a-487b-978f-81e406e9eb22 | 260.752 | 0.0 | 270.0 | NAYY 4x150SE 0.6/1kV | 0.2067 | 0.4 | 0.0804248 | simBench |
+| 1200d9eb-6d10-47f3-8543-abea43b128d3 | 273.319 | 0.0 | 357.0 | NAYY 4x240SE 0.6/1kV | 0.1267 | 0.4 | 0.0797965 | simBench |
+
+
+## Caveats
+
+Nothing - at least not known.
+If you found something, please contact us!
diff --git a/docs/readthedocs/models/input/grid/line.rst b/docs/readthedocs/models/input/grid/line.rst
deleted file mode 100644
index 7a1409c2b..000000000
--- a/docs/readthedocs/models/input/grid/line.rst
+++ /dev/null
@@ -1,71 +0,0 @@
-.. _line_model:
-
-Line
-----
-Representation of an AC line.
-
-Attributes, Units and Remarks
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Type Model
-""""""""""
-
-+-----------+---------+---------------------------------------------+
-| Attribute | Unit | Remarks |
-+===========+=========+=============================================+
-| uuid | -- | |
-+-----------+---------+---------------------------------------------+
-| id | -- | Human readable identifier |
-+-----------+---------+---------------------------------------------+
-| r | Ω / km | Phase resistance per length |
-+-----------+---------+---------------------------------------------+
-| x | Ω / km | Phase reactance per length |
-+-----------+---------+---------------------------------------------+
-| g | µS / km | Phase-to-ground conductance per length |
-+-----------+---------+---------------------------------------------+
-| b | µS / km | Phase-to-ground susceptance per length |
-+-----------+---------+---------------------------------------------+
-| iMax | A | Maximum permissible current |
-+-----------+---------+---------------------------------------------+
-| vRated | kV | Rated voltage |
-+-----------+---------+---------------------------------------------+
-
-Entity Model
-""""""""""""
-
-+-------------------+------+--------------------------------------------------------+
-| Attribute | Unit | Remarks |
-+===================+======+========================================================+
-| uuid | -- | |
-+-------------------+------+--------------------------------------------------------+
-| id | -- | Human readable identifier |
-+-------------------+------+--------------------------------------------------------+
-| operator | -- | |
-+-------------------+------+--------------------------------------------------------+
-| operationTime | -- | Timely restriction of operation |
-+-------------------+------+--------------------------------------------------------+
-| nodeA | -- | |
-+-------------------+------+--------------------------------------------------------+
-| nodeB | -- | |
-+-------------------+------+--------------------------------------------------------+
-| parallelDevices | -- | | overall amount of parallel lines to automatically |
-| | | | construct (e.g. parallelDevices = 2 will build a |
-| | | | total of two lines using the specified parameters) |
-+-------------------+------+--------------------------------------------------------+
-| type | -- | |
-+-------------------+------+--------------------------------------------------------+
-| length | km | |
-+-------------------+------+--------------------------------------------------------+
-| geoPosition | -- | | Line string of geographical locations describing the |
-| | | | position of the line |
-+-------------------+------+--------------------------------------------------------+
-| olmCharacteristic | -- | | Characteristic of possible overhead line monitoring |
-| | | | Can be given in the form of `olm:{}`. |
-| | | | The pairs are wind velocity in x and permissible |
-| | | | loading in y. |
-+-------------------+------+--------------------------------------------------------+
-
-Caveats
-^^^^^^^
-Nothing - at least not known.
-If you found something, please contact us!
diff --git a/docs/readthedocs/models/input/grid/transformer2w.md b/docs/readthedocs/models/input/grid/transformer2w.md
new file mode 100644
index 000000000..a213b09dc
--- /dev/null
+++ b/docs/readthedocs/models/input/grid/transformer2w.md
@@ -0,0 +1,77 @@
+# Two Winding Transformer
+
+Model of a two winding transformer.
+It is assumed, that node A is the node with higher voltage.
+
+## Attributes, Units and Remarks
+
+### Type Model
+
+All impedances and admittances are given with respect to the higher voltage side.
+As obvious, the parameter can be used in T- as in 𝜋-equivalent circuit representations.
+
+| Attribute | Unit | Remarks |
+|:----------|:-----|:--------------------------------------------------------|
+| id | | Human readable identifier |
+| rSc | Ω | Short circuit resistance |
+| xSc | Ω | Short circuit reactance |
+| gM | nS | No load conductance |
+| bM | nS | No load susceptance |
+| sRated | kVA | Rated apparent power |
+| vRatedA | kV | Rated voltage at higher voltage terminal |
+| vRatedB | kV | Rated voltage at lower voltage terminal |
+| dV | % | Voltage magnitude increase per tap position |
+| dPhi | ° | Voltage angle increase per tap position |
+| tapSide | | true, if tap changer is installed on lower voltage side |
+| tapNeutr | | Neutral tap position |
+| tapMin | | Minimum tap position |
+| tapMax | | Maximum tap position |
+
+A list with some standard transformer types can be found here: `Standard Two Winding Transformer Types`_
+
+
+### Entity Model
+
+| Attribute | Unit | Remarks |
+|:----------------|:-----|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| uuid | -- | |
+| id | -- | Human readable identifier |
+| operator | -- | |
+| operationTime | -- | Timely restriction of operation |
+| nodeA | -- | Higher voltage node |
+| nodeB | -- | Lower voltage node |
+| parallelDevices | -- | overall amount of parallel transformers to automatically
construct (e.g. parallelDevices = 2 will build a
total of two transformers using the specified parameters) |
+| type | -- | |
+| tapPos | -- | Current position of the tap changer |
+| autoTap | -- | true, if there is a tap regulation apparent and active |
+
+
+## Standard Two Winding Transformer Types
+
+
+Following there are some standard two winding transformer types with their source. A ``csv file`` containing the types listed
+below can be found `here `_. This
+file can be used directly for any simulation with ``simona``.
+The transformers which source is ``simBench`` are from `here `_.
+
+
+| uuid | bM | dPhi | dV | gM | id | rSc | sRated | tapMax | tapMin | tapNeutr | tapSide | vRatedA | vRatedB | xSc | source |
+|:-------------------------------------|--------------------:|-----:|----:|-------------------:|------------------------------------:|--------------------:|---------:|-------:|-------:|---------:|--------:|--------:|--------:|-------------------:|:---------|
+| 5a890aae-b9c9-4ebf-8a49-8850ae9df402 | 219.43184927638458 | 0.0 | 1.0 | 1731.3019390581715 | Typ_x_380/220 | 0.6016666666666666 | 600000.0 | 16 | -16 | 0 | false | 380.0 | 220.0 | 44.51926783240413 | simBench |
+| 03159c0d-126e-47cc-9871-066870df3a3f | 1193.4686938790917 | 0.0 | 1.0 | 831.0249307479223 | 350MVA_380/110 | 1.0608979591836734 | 350000.0 | 16 | -16 | 0 | false | 380.0 | 110.0 | 9 0.75951402093402 | simBench |
+| 7cb289cb-e6af-4470-9c68-e5a91978a5e7 | 2013.800484464662 | 0.0 | 1.0 | 1446.280991735537 | 300MVA_220/110 | 0.20704444444444442 | 300000.0 | 16 | -16 | 0 | false | 220.0 | 110.0 | 19.358892855688435 | simBench |
+| 73644bc6-78cf-4882-9837-e6508cab092d | 867.7685950413226 | 0.0 | 1.5 | 1157.0247933884295 | 25 MVA 110/20 kV YNd5 | 1.9843999999999997 | 25000.0 | 9 | -9 | 0 | false | 110.0 | 20.0 | 58.04608993412045 | simBench |
+| 6935ae26-374a-4c24-aeee-6d5760d6ddf3 | 720.4791642215993 | 0.0 | 1.5 | 1487.603305785124 | 40 MVA 110/20 kV YNd5 | 1.0285 | 40000.0 | 9 | -9 | 0 | false | 110.0 | 20.0 | 48.994205909984906 | simBench |
+| b49db20f-b8b5-4265-8318-f669b9d121e9 | 1015.6886939330394 | 0.0 | 1.5 | 1818.181818181818 | 63 MVA 110/10 kV YNd5 | .6146031746031745 | 63000.0 | 9 | -9 | 0 | false | 110.0 | 10.0 | 34.56596500037509 | simBench |
+| 0843b836-cee4-4a8c-81a4-098400fe91cf | 24.495101551166183 | 0.0 | 2.5 | 2999.9999999999995 | 0.4 MVA 20/0.4 kV Dyn5 ASEA | 11.999999999999998 | 400.0 | 2 | -2 | 0 | false | 20.0 | 0.4 | 58.787753826796276 | simBench |
+| a8f3aeea-ef4d-4f3c-bb07-09a0a86766c1 | 9.591746452043322 | 0.0 | 2.5 | 1149.9999999999998 | 0.16 MVA 20/0.4 kV DOTE 160/20 SGB | 36.71874999999999 | 160.0 | 2 | -2 | 0 | false | 20.0 | 0.4 | 93.01469452961452 | simBench |
+| 0644c120-a247-425f-bbe4-31b153f7f440 | 16.583241729259253 | 0.0 | 2.5 | 2199.9999999999995 | 0.25 MVA 20/0.4 kV Dyn5 ASEA | 21.119999999999997 | 250.0 | 2 | -2 | 0 | false | 20.0 | 0.4 | 93.6479876986153 | simBench |
+| bdf22ee4-deba-41f4-a187-ae00638a6880 | 36.47380569074435 | 0.0 | 2.5 | 4125.0 | 0.63 MVA 20/0.4 kV Dyn5 ASEA | 6.953892668178382 | 630.0 | 2 | -2 | 0 | false | 20.0 | 0.4 | 37.45518044666632 | simBench |
+| a0cbd90a-4e9f-47db-8dca-041d3a288f77 | 145.8952227629774 | 0.0 | 2.5 | 16500.0 | 0.63 MVA 10/0.4 kV Dyn5 ASEA | 1.7384731670445954 | 630.0 | 2 | -2 | 0 | false | 10.0 | 0.4 | 9.36379511166658 | simBench |
+
+
+
+## Caveats
+
+Nothing - at least not known.
+If you found something, please contact us!
diff --git a/docs/readthedocs/models/input/grid/transformer2w.rst b/docs/readthedocs/models/input/grid/transformer2w.rst
deleted file mode 100644
index 448e3fc54..000000000
--- a/docs/readthedocs/models/input/grid/transformer2w.rst
+++ /dev/null
@@ -1,82 +0,0 @@
-.. _transformer2w_model:
-
-Two Winding Transformer
------------------------
-Model of a two winding transformer.
-It is assumed, that node A is the node with higher voltage.
-
-Attributes, Units and Remarks
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Type Model
-""""""""""
-All impedances and admittances are given with respect to the higher voltage side.
-As obvious, the parameter can be used in T- as in 𝜋-equivalent circuit representations.
-
-+-----------+------+---------------------------------------------------------+
-| Attribute | Unit | Remarks |
-+===========+======+=========================================================+
-| uuid | | |
-+-----------+------+---------------------------------------------------------+
-| id | | Human readable identifier |
-+-----------+------+---------------------------------------------------------+
-| rSc | Ω | Short circuit resistance |
-+-----------+------+---------------------------------------------------------+
-| xSc | Ω | Short circuit reactance |
-+-----------+------+---------------------------------------------------------+
-| gM | nS | No load conductance |
-+-----------+------+---------------------------------------------------------+
-| bM | nS | No load susceptance |
-+-----------+------+---------------------------------------------------------+
-| sRated | kVA | Rated apparent power |
-+-----------+------+---------------------------------------------------------+
-| vRatedA | kV | Rated voltage at higher voltage terminal |
-+-----------+------+---------------------------------------------------------+
-| vRatedB | kV | Rated voltage at lower voltage terminal |
-+-----------+------+---------------------------------------------------------+
-| dV | % | Voltage magnitude increase per tap position |
-+-----------+------+---------------------------------------------------------+
-| dPhi | ° | Voltage angle increase per tap position |
-+-----------+------+---------------------------------------------------------+
-| tapSide | | true, if tap changer is installed on lower voltage side |
-+-----------+------+---------------------------------------------------------+
-| tapNeutr | | Neutral tap position |
-+-----------+------+---------------------------------------------------------+
-| tapMin | | Minimum tap position |
-+-----------+------+---------------------------------------------------------+
-| tapMax | | Maximum tap position |
-+-----------+------+---------------------------------------------------------+
-
-Entity Model
-""""""""""""
-
-+-----------------+------+------------------------------------------------------------+
-| Attribute | Unit | Remarks |
-+=================+======+============================================================+
-| uuid | -- | |
-+-----------------+------+------------------------------------------------------------+
-| id | -- | Human readable identifier |
-+-----------------+------+------------------------------------------------------------+
-| operator | -- | |
-+-----------------+------+------------------------------------------------------------+
-| operationTime | -- | Timely restriction of operation |
-+-----------------+------+------------------------------------------------------------+
-| nodeA | -- | Higher voltage node |
-+-----------------+------+------------------------------------------------------------+
-| nodeB | -- | Lower voltage node |
-+-----------------+------+------------------------------------------------------------+
-| parallelDevices | -- | | overall amount of parallel transformers to automatically |
-| | | | construct (e.g. parallelDevices = 2 will build a |
-| | | | total of two transformers using the specified parameters)|
-+-----------------+------+------------------------------------------------------------+
-| type | -- | |
-+-----------------+------+------------------------------------------------------------+
-| tapPos | -- | Current position of the tap changer |
-+-----------------+------+------------------------------------------------------------+
-| autoTap | -- | true, if there is a tap regulation apparent and active |
-+-----------------+------+------------------------------------------------------------+
-
-Caveats
-^^^^^^^
-Nothing - at least not known.
-If you found something, please contact us!
diff --git a/docs/readthedocs/models/models.md b/docs/readthedocs/models/models.md
new file mode 100644
index 000000000..c0e70ab78
--- /dev/null
+++ b/docs/readthedocs/models/models.md
@@ -0,0 +1,193 @@
+# Available models
+This page gives an overview about all available models in *PowerSystemDataModel*.
+They are basically grouped into two groups:
+
+1. [Input](#input) models may be used to describe input data for a power system simulation
+2. [Result](#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.
+
+**Copyable**
+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](https://en.wikipedia.org/wiki/Builder_pattern/) to make entity modifications as easy as possible.
+Each entity holds it's 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, that allows for modification of fields and
+can be terminated with `.build()` which will return an instance of the entity with modified field values as required.
+For the moment, this pattern is only implemented for a small amount of `AssetInput` entities (all entities held by a
+`GridContainer` except thermal units to be precise), but we plan to extend this capability to all input entities in the
+future.
+
+**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 it's geographical location in the model of it's common
+coupling point ([node](/models/input/grid/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](https://github.com/unitsofmeasurement/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(, )` or
+ `.equals()`.
+ Using `Objects.equals(, )` 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 of `null`
+ 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 using `null` 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` or `Double` instances. It is important, that the object type is also the same, otherwise
+ the entities `equals()` 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
+ method `AbstractQuantity.to(Quantity)` which may return seemingly unexpected types, e.g. if called on a quantity
+ with a `double` typed value, it may return a quantity with a value of either `Double` type or `BigDecimal` 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 return `false` 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 their `isEquivalentTo()`
+ method. If you think you would benefit from a standard method that allows entity equivalence check, please consider
+ handing in an issue [Issues](https://github.com/ie3-institute/PowerSystemDataModel/issues).
+ Furthermore, the current existing implementation of `isEquivalentTo()` 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](https://github.com/ie3-institute/PowerSystemUtils) library.
+ If you think you would benefit from such a method, please consider handing in an issue
+ [Issues](https://github.com/ie3-institute/PowerSystemUtils/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](/io/ValidationUtils).
+
+
+## Input
+Model classes you can use to describe a data set as input to power system simulations.
+
+```{toctree}
+---
+maxdepth: 1
+---
+input/operator
+```
+
+### Grid Related Models
+
+```{toctree}
+---
+maxdepth: 1
+---
+input/grid/node
+input/grid/nodegraphic
+input/grid/line
+input/grid/linegraphic
+input/grid/switch
+input/grid/transformer2w
+input/grid/transformer3w
+input/grid/measurementunit
+input/grid/gridcontainer
+```
+
+### Participant Related Models
+
+```{toctree}
+---
+maxdepth: 1
+---
+input/participant/general
+input/participant/bm
+input/participant/chp
+input/participant/ev
+input/participant/evcs
+input/participant/fixedfeedin
+input/participant/hp
+input/participant/load
+input/participant/pv
+input/participant/storage
+input/participant/wec
+input/participant/thermalbus
+input/participant/thermalhouse
+input/participant/cylindricalstorage
+```
+
+### Additional Data
+Some models can use additional data for their calculations.
+
+```{toctree}
+---
+maxdepth: 1
+---
+input/additionaldata/timeseries
+input/additionaldata/idcoordinatesource
+```
+
+## Result
+Model classes you can use to describe the outcome of a power system simulation.
+
+### Grid Related Models
+
+```{toctree}
+---
+maxdepth: 1
+---
+result/grid/node
+result/grid/connector
+result/grid/line
+result/grid/switch
+result/grid/transformer
+result/grid/transformer2w
+result/grid/transformer3w
+```
+
+### Participant Related Models
+
+```{toctree}
+---
+maxdepth: 1
+---
+result/participant/bm
+result/participant/chp
+result/participant/ev
+result/participant/evcs
+result/participant/fixedfeedin
+result/participant/hp
+result/participant/load
+result/participant/pv
+result/participant/storage
+result/participant/wec
+result/participant/thermalsink
+result/participant/thermalstorage
+result/participant/thermalunit
+result/participant/thermalhouse
+result/participant/cylindricalstorage
+result/participant/systemparticipant
+result/participant/flexoption
+result/participant/em
+```
diff --git a/docs/readthedocs/models/models.rst b/docs/readthedocs/models/models.rst
deleted file mode 100644
index 9b738fb72..000000000
--- a/docs/readthedocs/models/models.rst
+++ /dev/null
@@ -1,224 +0,0 @@
-################
-Available models
-################
-This page gives an overview about all available models in *PowerSystemDataModel*.
-They are basically grouped into three groups:
-
- 1. `Input`_ models may be used to describe input data for a power system simulation
- 2. `Result`_ models denote results of such a simulation
- 3. `Time Series`_ may serve both as input or output
-
-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 :code:`uuid` field as universal unique identifier.
- There shouldn't be any two elements with the same :code:`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.
-
-Copyable
- 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 it's 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, that allows for modification of fields and
- can be terminated with `.build()` which will return an instance of the entity with modified field values as required.
- For the moment, this pattern is only implemented for a small amount of `AssetInput` entities (all entities held by a
- `GridContainer` except thermal units to be precise), but we plan to extend this capability to all input entities in the
- future.
-
-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 it's geographical location in the model of it's common
- coupling point (:ref:`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 :code:`equals()` method, we agreed on the following rules to be applied:
-
- - equality check is done by calling :code:`Objects.equals(, )` or
- :code:`.equals()`.
- Using :code:`Objects.equals(, )` 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 of :code:`null`
- 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 using :code:`null` 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. :code:`BigDecimal` or :code:`Double` instances. It is important, that the object type is also the same, otherwise
- the entities :code:`equals()` 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
- method :code:`AbstractQuantity.to(Quantity)` which may return seemingly unexpected types, e.g. if called on a quantity
- with a :code:`double` typed value, it may return a quantity with a value of either :code:`Double` type or :code:`BigDecimal` 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 :code:`LineA.equals(LineB)`
- would return :code:`false` 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 their :code:`isEquivalentTo()`
- method. If you think you would benefit from a standard method that allows entity equivalence check, please consider
- handing in an issue `here `__.
- Furthermore, the current existing implementation of :code:`isEquivalentTo()` 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
- `here `__.
-
-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
- :code:`operationTime` where :code:`operationStartTime` and :code:`operationEndTime` are both :code:`null` or :code:`""`, the
- factory will build an always-on line model.
-
-*****
-Input
-*****
-Model classes you can use to describe a data set as input to power system simulations.
-
-.. toctree::
- :maxdepth: 1
-
- input/operator
-
-Grid Related Input Models
-=========================
-.. toctree::
- :maxdepth: 1
-
- input/grid/node
- input/grid/nodegraphic
- input/grid/line
- input/grid/linegraphic
- input/grid/switch
- input/grid/transformer2w
- input/grid/transformer3w
- input/grid/measurementunit
- input/grid/gridcontainer
-
-Participant Related Input Models
-================================
-.. toctree::
- :maxdepth: 1
-
- input/participant/general
- input/participant/bm
- input/participant/chp
- input/participant/ev
- input/participant/evcs
- input/participant/fixedfeedin
- input/participant/hp
- input/participant/load
- input/participant/pv
- input/participant/storage
- input/participant/wec
- input/participant/thermalbus
- input/participant/thermalhouse
- input/participant/cylindricalstorage
-
-******
-Result
-******
-Model classes you can use to describe the outcome of a power system simulation.
-
-Grid Related Result Models
-==========================
-.. toctree::
- :maxdepth: 1
-
- result/grid/node
- result/grid/connector
- result/grid/line
- result/grid/switch
- result/grid/transformer
- result/grid/transformer2w
- result/grid/transformer3w
-
-Participant Related Result Models
-=================================
-.. toctree::
- :maxdepth: 1
-
- result/participant/bm
- result/participant/chp
- result/participant/ev
- result/participant/evcs
- result/participant/fixedfeedin
- result/participant/hp
- result/participant/load
- result/participant/pv
- result/participant/storage
- result/participant/wec
- result/participant/thermalsink
- result/participant/thermalstorage
- result/participant/thermalunit
- result/participant/thermalhouse
- result/participant/cylindricalstorage
- result/participant/systemparticipant
-
-***********
-Time Series
-***********
-Time series are meant to represent a timely ordered series of values.
-Those can either be electrical or non-electrical depending on what one may need for power system simulations.
-Our time series models are divided into two subtypes:
-
-.. _individual_time_series:
-
-Individual Time Series
- Each time instance in this time series has its own value (random duplicates may occur obviously).
- They are only applicable for the time frame that is defined by the content of the time series.
-
-.. _repetitive_time_series:
-
-Repetitive Time Series
- Those time series do have repetitive values, e.g. each day or at any other period.
- Therefore, they can be applied to any time frame, as the mapping from time instant to value is made by information
- reduction.
- In addition to actual data, a mapping function has to be known.
-
-To be as flexible, as possible, the actual content of the time series is given as children of the :code:`Value` class.
-The following different values are available:
-
-+-------------------------------+------------------------------------------------------------------+
-| Value Class | Purpose |
-+===============================+==================================================================+
-| :code:`PValue` | Electrical active power |
-+-------------------------------+------------------------------------------------------------------+
-| :code:`SValue` | Electrical active and reactive power |
-+-------------------------------+------------------------------------------------------------------+
-| :code:`HeatAndPValue` | | Combination of thermal power (e.g. in kW) |
-| | | and electrical active power (e.g. in kW) |
-+-------------------------------+------------------------------------------------------------------+
-| :code:`HeatAndSValue` | | Combination of thermal power (e.g. in kW) |
-| | | and electrical active and reactive power (e.g. in kW and kVAr) |
-+-------------------------------+------------------------------------------------------------------+
-| :code:`EnergyPriceValue` | Wholesale market price (e.g. in € / MWh) |
-+-------------------------------+------------------------------------------------------------------+
-| :code:`SolarIrradianceValue` | Combination of diffuse and direct solar irradiance |
-+-------------------------------+------------------------------------------------------------------+
-| :code:`TemperatureValue` | Temperature information |
-+-------------------------------+------------------------------------------------------------------+
-| :code:`WindValue` | Combination of wind direction and wind velocity |
-+-------------------------------+------------------------------------------------------------------+
-| :code:`WeatherValue` | Combination of irradiance, temperature and wind information |
-+-------------------------------+------------------------------------------------------------------+
-
-.. include:: ValidationUtils.rst
-
diff --git a/docs/readthedocs/models/result/grid/switch.rst b/docs/readthedocs/models/result/grid/switch.rst
index bde8c39eb..aa11cda90 100644
--- a/docs/readthedocs/models/result/grid/switch.rst
+++ b/docs/readthedocs/models/result/grid/switch.rst
@@ -16,14 +16,6 @@ Attributes, Units and Remarks
+---------------+----------------+----------------------------------------------------------+
| inputModel | -- | uuid for the associated input model |
+---------------+----------------+----------------------------------------------------------+
-| iAMag | ampere | A stands for sending node |
-+---------------+----------------+----------------------------------------------------------+
-| iAAng | degree | |
-+---------------+----------------+----------------------------------------------------------+
-| iBMag | ampere | B stands for receiving node |
-+---------------+----------------+----------------------------------------------------------+
-| iBAng | degree | |
-+---------------+----------------+----------------------------------------------------------+
| closed | boolean | status of the switching device |
+---------------+----------------+----------------------------------------------------------+
diff --git a/docs/readthedocs/models/result/participant/em.rst b/docs/readthedocs/models/result/participant/em.rst
new file mode 100644
index 000000000..90f47b1cb
--- /dev/null
+++ b/docs/readthedocs/models/result/participant/em.rst
@@ -0,0 +1,29 @@
+.. _em_result:
+
+Energy Management
+-----------------
+Result of an energy management entity.
+
+Attributes, Units and Remarks
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
++---------------+---------+----------------------------------------------------------------------------+
+| Attribute | Unit | Remarks |
++===============+=========+============================================================================+
+| uuid | -- | uuid for the result entity |
++---------------+---------+----------------------------------------------------------------------------+
+| time | -- | date and time for the produced result |
++---------------+---------+----------------------------------------------------------------------------+
+| inputModel | -- | uuid for the associated input model |
++---------------+---------+----------------------------------------------------------------------------+
+| p | MW | active power output |
++---------------+---------+----------------------------------------------------------------------------+
+| q | MW | reactive power output |
++---------------+---------+----------------------------------------------------------------------------+
+
+
+Caveats
+^^^^^^^
+Nothing - at least not known.
+If you found something, please contact us!
+
diff --git a/docs/readthedocs/models/result/participant/flexoption.rst b/docs/readthedocs/models/result/participant/flexoption.rst
new file mode 100644
index 000000000..e2abe9547
--- /dev/null
+++ b/docs/readthedocs/models/result/participant/flexoption.rst
@@ -0,0 +1,30 @@
+.. _flexoption_result:
+
+Flexibility Option
+------------------
+Result of a flexibility option.
+
+Attributes, Units and Remarks
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
++---------------+---------+----------------------------------------------------------------------------+
+| Attribute | Unit | Remarks |
++===============+=========+============================================================================+
+| uuid | -- | uuid for the result entity |
++---------------+---------+----------------------------------------------------------------------------+
+| time | -- | date and time for the produced result |
++---------------+---------+----------------------------------------------------------------------------+
+| inputModel | -- | uuid for the associated input model |
++---------------+---------+----------------------------------------------------------------------------+
+| pRef | MW | active power that was suggested for regular usage by the system participant|
++---------------+---------+----------------------------------------------------------------------------+
+| pMin | MW | active minimal power that was determined by the system participant |
++---------------+---------+----------------------------------------------------------------------------+
+| pMax | MW | active maximum power that was determined by the system participant |
++---------------+---------+----------------------------------------------------------------------------+
+
+Caveats
+^^^^^^^
+Nothing - at least not known.
+If you found something, please contact us!
+
diff --git a/docs/readthedocs/models/result/participant/hp.rst b/docs/readthedocs/models/result/participant/hp.rst
index e5fe4f2e1..5c51b59c4 100644
--- a/docs/readthedocs/models/result/participant/hp.rst
+++ b/docs/readthedocs/models/result/participant/hp.rst
@@ -1,7 +1,7 @@
.. _hp_result:
-Load
-----
+Heat Pump
+---------
Result of a heat pump.
Attributes, Units and Remarks
diff --git a/docs/readthedocs/requirements.txt b/docs/readthedocs/requirements.txt
index 605bbfa69..36dad5c08 100644
--- a/docs/readthedocs/requirements.txt
+++ b/docs/readthedocs/requirements.txt
@@ -1,4 +1,6 @@
commonmark==0.9.1
recommonmark==0.7.1
-Sphinx==5.3.0
-sphinx-rtd-theme==1.2.0
+Sphinx==6.2.1
+sphinx-rtd-theme==1.2.2
+myst-parser==2.0.0
+markdown-it-py==3.0.0
diff --git a/docs/uml/main/DataSourceClassDiagram.puml b/docs/uml/main/DataSourceClassDiagram.puml
index 77a8e2976..5f05c566f 100644
--- a/docs/uml/main/DataSourceClassDiagram.puml
+++ b/docs/uml/main/DataSourceClassDiagram.puml
@@ -2,197 +2,166 @@
note "Assuming all classes to implement \nthe abstract methods of their interfaces\n\n" as generalNotes
-interface DataSource
-
-interface TypeSource {
- {abstract} Set getTransformer2WTypes()
- {abstract} Set getTransformer3WTypes()
- {abstract} Set getOperators()
- {abstract} Set getLineTypes()
- {abstract} Set getBmTypes()
- {abstract} Set getChpTypes()
- {abstract} Set getHpTypes()
- {abstract} Set getStorageTypes()
- {abstract} Set getWecTypes()
- {abstract} Set getEvTypes()
-}
-DataSource <|-- TypeSource
-
-interface ThermalSource {
- {abstract} Set getThermalBuses()
- {abstract} Set getThermalBuses(Set)
- {abstract} Set getThermalStorages()
- {abstract} Set getThermalStorages(Set, Set)
- {abstract} Set getThermalHouses()
- {abstract} Set getThermalHouses(Set, Set)
- {abstract} Set getCylindricStorages()
- {abstract} Set getCylindricStorages(Set, Set)
-}
-DataSource <|-- ThermalSource
-
-interface RawGridSource {
- {abstract} Optional getGridData()
- {abstract} Set getNodes()
- {abstract} Set getNodes(Set)
- {abstract} Set getLines()
- {abstract} Set getLines(Set, Set, Set)
- {abstract} Set get2WTransformers()
- {abstract} Set get2WTransformers(Set, Set, Set)
- {abstract} Set get3WTransformers()
- {abstract} Set get3WTransformers(Set, Set, Set)
- {abstract} Set getSwitches()
- {abstract} Set getSwitches(Set, Set)
- {abstract} Set getMeasurementUnits()
- {abstract} Set getMeasurementUnits(Set, Set)
-}
-DataSource <|-- RawGridSource
-
-interface SystemParticipantSource{
- {abstract} Optional getSystemParticipants()
- {abstract} Set getBmPlants()
- {abstract} Set getBmPlants(Set, Set, Set)
- {abstract} Set getChpPlants()
- {abstract} Set getChpPlants(Set, Set, Set, Set, Set)
- {abstract} Set getEvs()
- {abstract} Set getEvs(Set, Set, Set)
- {abstract} Set getEvCS()
- {abstract} Set getEvCS(Set, Set)
- {abstract} Set getFixedFeedIns()
- {abstract} Set getFixedFeedIns(Set, Set)
- {abstract} Set getHeatPumps()
- {abstract} Set getHeatPumps(Set, Set, Set, Set)
- {abstract} Set getLoads()
- {abstract} Set getLoads(Set, Set)
- {abstract} Set getPvPlants()
- {abstract} Set getPvPlants(Set, Set)
- {abstract} Set getStorages()
- {abstract} Set getStorages(Set, Set, Set)
- {abstract} Set getWecPlants()
- {abstract} Set getWecPlants(Set, Set, Set)
-}
-DataSource <|-- SystemParticipantSource
-
-interface GraphicSource {
- {abstract} Optional getGraphicElements()
- {abstract} Set getNodeGraphicInput()
- {abstract} Set getNodeGraphicInput(Set)
- {abstract} Set getLineGraphicInput()
- {abstract} Set getLineGraphicInput(Set)
-}
-DataSource <|-- GraphicSource
-
-interface WeatherSource {
- {abstract} Map> getWeather(ClosedInterval)
- {abstract} Map> getWeather(ClosedInterval, Collection)
- {abstract} WeatherValue getWeather(ZonedDateTime date, Point coordinate)
-}
-DataSource <|-- WeatherSource
-
-interface TimeSeriesMappingSource {
- {abstract} Map getMapping()
- Optional getTimeSeriesUuid(UUID)
- {abstract} Optional getTimeSeriesMetaInformation(UUID)
-}
-DataSource <|-- TimeSeriesMappingSource
+interface DataSource {
+ {abstract} Stream