Merge branch 'dev' into ms/#795-remove-support-for-old-csv-format

# Conflicts:
#	CHANGELOG.md
#	src/main/java/edu/ie3/datamodel/io/source/csv/CsvDataSource.java
#	src/test/resources/edu/ie3/datamodel/io/source/csv/_joint_grid/line_input.csv

Author: staudtMarius

CHANGELOG.md

@@ -11,6 +11,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Implementing missing typical methods in `Try` [#970](https://github.com/ie3-institute/PowerSystemDataModel/issues/970)
 - Added log warning when using `SwitchInputs` with `parallelDevices` parameter [#840](https://github.com/ie3-institute/PowerSystemDataModel/issues/840)
 - Validation for `EvcsInput` [#1000](https://github.com/ie3-institute/PowerSystemDataModel/issues/1000)
+- Scaling method in system participant copy builders [#1011](https://github.com/ie3-institute/PowerSystemDataModel/issues/1011)
+- Added separate field for maximum power limit for DC to evtype [#876](https://github.com/ie3-institute/PowerSystemDataModel/issues/876)
+- Added test for invalid input data in `CsvRawGridSource` [#1021](https://github.com/ie3-institute/PowerSystemDataModel/issues/1021)
 
 ### Fixed
 - Fixed Couchbase integration tests that randomly failed [#755](https://github.com/ie3-institute/PowerSystemDataModel/issues/755)
@@ -19,6 +22,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Fixed thermal-house-documentation [#873](https://github.com/ie3-institute/PowerSystemDataModel/issues/873)
 - Fixed ElectricVehicle Documentation [#875](https://github.com/ie3-institute/PowerSystemDataModel/issues/875)
 - Fixed Equal behavior of `ConnectorResult` [#1001](https://github.com/ie3-institute/PowerSystemDataModel/issues/1001) 
+- Fixed test for invalid input data in `CsvGraphicSource` [#1022](https://github.com/ie3-institute/PowerSystemDataModel/issues/1022)
 
 ### Changed
 - Changing from comparing strings to comparing uuids in `EntitySource.findFirstEntityByUuid` [#829](https://github.com/ie3-institute/PowerSystemDataModel/issues/829)
@@ -33,6 +37,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Refactored and abstracted `EntitySource`s and `EntityData` creation [#969](https://github.com/ie3-institute/PowerSystemDataModel/issues/969)
 - Updated contributing.md [#737](https://github.com/ie3-institute/PowerSystemDataModel/issues/737)
 - Don't throw exceptions for not yet implemented validations [#879](https://github.com/ie3-institute/PowerSystemDataModel/issues/879)
+- `CsvDataSource` throws exceptions on error [#954](https://github.com/ie3-institute/PowerSystemDataModel/issues/954)
+- Removing `uuid` as required column from input and result time series [#826](https://github.com/ie3-institute/PowerSystemDataModel/issues/826)
 - Removing the support for the old csv format that was marked `deprecated` back in version `1.1.0` [#795](https://github.com/ie3-institute/PowerSystemDataModel/issues/795)
 
 ## [4.1.0] - 2023-11-02

build.gradle

@@ -18,7 +18,7 @@ ext {
   javaVersion = JavaVersion.VERSION_17
   groovyVersion = "4.0"
   groovyBinaryVersion = "4.0.18"
-  testcontainersVersion = '1.19.4'
+  testcontainersVersion = '1.19.6'
 
   scriptsLocation = 'gradle' + File.separator + 'scripts' + File.separator //location of script plugins
 }
@@ -73,7 +73,7 @@ dependencies {
   testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'
   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.14.11' // Mocks of classes
+  testImplementation 'net.bytebuddy:byte-buddy:1.14.12' // Mocks of classes
 
   // testcontainers (docker framework for testing)
   testImplementation "org.testcontainers:testcontainers:$testcontainersVersion"
@@ -83,19 +83,19 @@ dependencies {
   testImplementation "org.testcontainers:couchbase:$testcontainersVersion"
 
   // logging
-  implementation platform('org.apache.logging.log4j:log4j-bom:2.22.1')
+  implementation platform('org.apache.logging.log4j:log4j-bom:2.23.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.24'
-  implementation 'com.couchbase.client:java-client:3.5.2'
-  runtimeOnly 'org.postgresql:postgresql:42.7.1' // postgresql jdbc driver required during runtime
+  implementation 'com.couchbase.client:java-client:3.5.3'
+  runtimeOnly 'org.postgresql:postgresql:42.7.2' // postgresql jdbc driver required during runtime
 
   implementation 'commons-io:commons-io:2.15.1' // I/O functionalities
-  implementation 'org.apache.commons:commons-compress:1.25.0' // I/O functionalities
-  implementation 'org.apache.commons:commons-lang3:3.14.0'
+  implementation 'commons-codec:commons-codec:1.16.1' // needed by commons-compress
+  implementation 'org.apache.commons:commons-compress:1.26.0' // I/O functionalities
 }
 
 tasks.withType(JavaCompile) {

docs/readthedocs/io/ValidationUtils.md

@@ -2,15 +2,31 @@
 This page gives an overview about the ValidationUtils in the *PowerSystemDataModel*.
 
 ## 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.
+The methods in ValidationUtils and subclasses can be used to check that objects are valid. The checks can be separated into two types:
+1. General validation
+2. Uniqueness validation
+
 
 ## 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.
+The general validation checks:
+- if 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.
+
+The uniqueness validation checks if a collection of given objects are unique in either:
+- a specific field
+- or in a combination of multiple fields
+
+For example `AssetInputs` needs to be unique in their `uuid` and in their `id` while
+`weather values` needs to be unique in the combination of their `time` and their `coordinate`.
+
+
+## How to use?
+- To use the general validation the user should call the method `ValidationUtils.check(Object)`.
+- To use the uniqueness validation the user should call a method of `UniquenessValidationUtils` to check the uniqueness.
+
+## How does the general validation work?
 
-## 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 method `ValidationUtils.check(Object)` 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 `LineInput lineInput` should be checked
     1. `ValidationUtils.check(lineInput)` is called
@@ -49,15 +65,14 @@ The ValidationUtils include validation checks for...
         - PvInput
         - StorageInput
         - WecInput
-        - (missing: EvcsInput)
+        - EvcsInput (also checks ChargingPointType)
     - SystemParticipantTypeInput
         - BmTypeInput
         - ChpTypeInput
         - EvTypeInput
         - HpTypeInput
         - StorageTypeInput
         - WecTypeInput
-        - (missing: EvcsTypeInput/ChargingPointType)
 - ThermalUnitValidationUtils
     - ThermalUnitInput
         - ThermalSinkInput

docs/readthedocs/io/csvfiles.md

@@ -58,7 +58,7 @@ You may extend / alter the naming with pre- or suffix by calling `new EntityPers
 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
+To be able to understand, what's inside of the file, the *columnScheme* part of the file name gives insight of its
 content.
 The following keys are supported until now:
 

docs/readthedocs/models/input/participant/ev.md

@@ -45,12 +45,16 @@ Model of an electric vehicle, that is occasionally connected to the grid via an
 
    * - sRated
      - kVA
-     - Rated apparent power
+     - Rated apparent power for AC
+     
+   * - sRatedDC
+     - kW
+     - power for DC
 
    * - cosPhiRated
      - --
      - Rated power factor
-
+     
 ```
 
 ### Entity Model

docs/readthedocs/models/input/participant/load.md

@@ -77,7 +77,7 @@ If you found something, please contact us!
 
 ## Load Profiles
 
-The {code}`LoadProfile` is an interface, that forces it's implementing classes to have a {code}`String` *key*
+The {code}`LoadProfile` is an interface, that forces its implementing classes to have a {code}`String` *key*
 and being able to parse a {code}`String` to a {code}`LoadProfile`.
 Its only purpose is to give note, which load profile has to be used by the simulation.
 The actual profile has to be provided by the simulation itself.

docs/readthedocs/models/models.md

@@ -18,22 +18,26 @@ We designed the models in a way, that does not allow for adaptions of the repres
 objects.
 Thereby you can be sure, that your models are *thread-safe* and no unwanted or unobserved changes are made.
 
-**Copyable** <br>
+**Clonability** <br>
 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.
+Each entity holds its own copy builder class, which follows the same inheritance as the entity class itself. With a
+call of `.copy()` on an entity instance a builder instance is returned, which allows for modification of fields and
+can be terminated with `.build()`. This will return an instance of the entity with modified field values as indicated.
+For the moment, this pattern is only implemented for a limited set of entities, but we plan to extend this capability 
+to all input entities in the future.
+
+**Scaling entity properties** <br>
+Using the copy builders (as described above) we provide a convenience method that helps with scaling system 
+participants and respective type inputs. Scaling entities tries to preserve proportions that are related to power. 
+This means that capacity, consumption etc. are scaled with the same factor as power.
 
 **Single Point of Truth** <br>
 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
+energy converter in detail, you may find information of its geographical location in the model of its common
 coupling point ([node](/models/input/grid/node)).
 
 **Harmonized Units System** <br>

docs/readthedocs/models/result/grid/connector.md

@@ -16,10 +16,6 @@ Representation of all kinds of connectors.
      - Unit
      - Remarks
 
-   * - uuid
-     - --
-     - uuid for the result entity
-
    * - time
      - ZonedDateTime
      - date and time for the produced result

docs/readthedocs/models/result/grid/line.md

@@ -16,10 +16,6 @@ Representation of an AC line.
      - Unit
      - Remarks
 
-   * - uuid
-     - --
-     - uuid for the result entity
-
    * - time
      - ZonedDateTime
      - date and time for the produced result

docs/readthedocs/models/result/grid/node.md

@@ -16,10 +16,6 @@ Representation of an electrical node, with no further distinction into bus bar,
      - Unit
      - Remarks
 
-   * - uuid
-     - --
-     - uuid for the result entity
-
    * - time
      - ZonedDateTime
      - date and time for the produced result