@@ -515,6 +519,28 @@ Maybe it could be developed into a more serious paper later.
+
Simulation of energy supply and consumption of buildings at the level of districts or even cities not only requires elaborated algorithms but also careful design of model structure and parameters.
+Structural aspects include building geometry as well as arrangement of buildings, e.g. to take shadowing and heat transfer into account.
+Assigning usage patterns or energy components like heat pumps, PV, boilers, etc. to specific buildings also count as structural aspects of a simulation model.
+Moreover, this multitude of model entities has to be defined in more detail by lots of numeric, ordinal or nominal parameters.
+Our experience with developing simulation systems like INSEL and SimStadt showed that manual parametrization based on informal data collections, typologies, spreadsheet tables, etc. from different sources is tedious and often hard to reproduce. Instead, parametrization of complex models should be supported by software providing formally defined parameter catalogs, that are systematically created and updated by domain experts.
+
+
+
Parameter catalogs and the software to create, maintain and deploy them should be independent of any specific simulation software to enhance software modularity (separation of concerns).
+Ideally, modelers can enhance their simulation environment by adding suited parameter catalogs as software plug-ins and use them to parametrize model entities easily, e.g. via drag and drop.
+
+
+
Automatic parametrization of components in simulation models requires a formal data model which fits the simulation models in terms of content and structure and can pass information to them.
+Self-contained parameter catalogs fulfill this requirement by providing an application programmers interface (API) that can be queried for automatic, rule-based parametrization of simulation models.
+
+
+
To get good results fast, close collaboration with domain experts and short development cycles are desirable.
+We achieved this by exploiting techniques of so called low code development.
+Basically this means that domain experts encode their knowledge into a graphical diagram defining types of components, their relations, and attributes.
+From this diagram, program code for storing and manipulating data sets in main memory as well as code to write and read that data to and from XML files (or data bases) are automatically generated.
+A modern graphical user interface to create, read, update, and delete data (CRUD operations) can also be provided with no or very few lines of manually written code.
+
+
The overall motivation for the work on parameter catalogs for simulation is to make easier to develop and perform computer simulations in complex and data rich domains like building physics, transportation, and all kinds of urban infrastructure.
@@ -638,7 +664,7 @@ It was developed in Java with a user interface written in JavaFX and was well re
-
Low-Code-Development of Parameter Catalogs
+
Low-Code-Development of Parameter Catalogs
From INSEL and SimStadt we learned, that manual and automatic construction and parameterization of complex simulation models with many types of interrelated objects should be supported be the means of domain specific parameter catalogs.
@@ -1238,7 +1264,7 @@ Instead of artificial example classes like Foo and Bar it show
-
+
Figure 4. Principle Structure of a Parameter Catalog
@@ -2024,65 +2050,24 @@ An enumeration introduced a new attribute type as a set of named values.
-
Accessing and Using Parameter Catalogs
+
TBD: Accessing and Using Parameter Catalogs
-
Accessing XML-Catalogs
-
-
Add Ecore data model to a third-party Java application
Building an application "around" the three plugins for Ecore data model and UI specification model.
-
-
See template.
-
Create an Eclipse Application
-
-
TBD
-
+
Use Maven and Tycho as Build System
@@ -2160,18 +2140,7 @@ Verify that Maven version 3.6.3 or above is now installed in Window →
Figure 26. Check Maven installation
-
"Mavenize" projects
-
TBD
-
-
-
Build and Deploy with Tycho
-
TBD
-
-
Add third party Java libraries
-
TBD
-
-
"Correct" way to add third party Java libraries as plugins
@@ -2180,15 +2149,11 @@ Verify that Maven version 3.6.3 or above is now installed in Window →
Deploy to P2 Repository
-
-
TBD
-
+
Versioning and Collaboration
-
-
TBD
-
+
@@ -2222,7 +2187,7 @@ Verify that Maven version 3.6.3 or above is now installed in Window →
diff --git a/ParameterCatalogs.pdf b/ParameterCatalogs.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..26a17196163b90e45308e8baf3b8b5660735ef27
Binary files /dev/null and b/ParameterCatalogs.pdf differ
diff --git a/ParameterCatalogs1Overview.adoc b/ParameterCatalogs1Overview.adoc
index 66522608c838dfc242b937ff1c36428b9610f560..f63682606a155320161e1086235e45cf47a3ac4d 100644
--- a/ParameterCatalogs1Overview.adoc
+++ b/ParameterCatalogs1Overview.adoc
@@ -6,8 +6,27 @@ This introduction talks about the work of the author and others, but without bib
Maybe it could be developed into a more serious paper later.
====
+Simulation of energy supply and consumption of buildings at the level of districts or even cities not only requires elaborated algorithms but also careful design of model structure and parameters.
+Structural aspects include building geometry as well as arrangement of buildings, e.g. to take shadowing and heat transfer into account.
+Assigning usage patterns or energy components like heat pumps, PV, boilers, etc. to specific buildings also count as structural aspects of a simulation model.
+Moreover, this multitude of model entities has to be defined in more detail by lots of numeric, ordinal or nominal parameters.
+Our experience with developing simulation systems like INSEL and SimStadt showed that manual parametrization based on informal data collections, typologies, spreadsheet tables, etc. from different sources is tedious and often hard to reproduce. Instead, parametrization of complex models should be supported by software providing formally defined *parameter catalogs*, that are systematically created and updated by domain experts.
+
+Parameter catalogs and the software to create, maintain and deploy them should be independent of any specific simulation software to enhance software modularity (separation of concerns).
+Ideally, modelers can enhance their simulation environment by adding suited parameter catalogs as software plug-ins and use them to parametrize model entities easily, e.g. via drag and drop.
+
+Automatic parametrization of components in simulation models requires a formal data model which fits the simulation models in terms of content and structure and can pass information to them.
+Self-contained parameter catalogs fulfill this requirement by providing an application programmers interface (API) that can be queried for automatic, rule-based parametrization of simulation models.
+
+To get good results fast, close collaboration with domain experts and short development cycles are desirable.
+We achieved this by exploiting techniques of so called *low code development*.
+Basically this means that domain experts encode their knowledge into a graphical diagram defining types of components, their relations, and attributes.
+From this diagram, program code for storing and manipulating data sets in main memory as well as code to write and read that data to and from XML files (or data bases) are automatically generated.
+A modern graphical user interface to create, read, update, and delete data (CRUD operations) can also be provided with no or very few lines of manually written code.
+
The overall motivation for the work on parameter catalogs for simulation is to make easier to develop and perform computer simulations in complex and _data rich_ domains like building physics, transportation, and all kinds of urban infrastructure.
+
=== The Bigger Picture
A good part of computer science was and is driven by the motivation to make it easier to develop computer programs of all sorts.
@@ -79,7 +98,7 @@ It was developed in Java with a user interface written in JavaFX and was well re
However, as a different catalog -- this time for building usages -- had to be created, it was quite difficult to reuse the XML schema and application code from the building physics catalog: The usage catalog data model was "pressed" into a form similar to the building physics catalog data model, and the UI code was "over-engineered" to accommodate both catalog's requirements.
-
+[#low-code-development]
=== Low-Code-Development of Parameter Catalogs
From INSEL and SimStadt we learned, that manual and automatic construction and parameterization of complex simulation models with many types of interrelated objects should be supported be the means of domain specific parameter catalogs.
diff --git a/ParameterCatalogs3Usage.adoc b/ParameterCatalogs3Usage.adoc
index fc5c2d7863db3b41f3ebb5306bf1654ef12b6ae0..5bb5073383cef0735a90a9912dafb3425a227bb4 100644
--- a/ParameterCatalogs3Usage.adoc
+++ b/ParameterCatalogs3Usage.adoc
@@ -1,46 +1,16 @@
-== Accessing and Using Parameter Catalogs
+[#using-parameter-catalogs]
+== TBD: Accessing and Using Parameter Catalogs
-=== Accessing XML-Catalogs
+=== Accessing XML-Catalogs from Java
-.Add Ecore data model to a third-party Java application
-*TBD*
-
- import java.util.Collection;
- import org.eclipse.emf.common.util.URI;
- import org.eclipse.emf.ecore.resource.Resource;
- import org.eclipse.emf.ecore.resource.ResourceSet;
- import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;
- import org.eclipse.emf.ecore.util.EcoreUtil;
- import de.hftstuttgart.energycomponents.EnCompPackage;
- import de.hftstuttgart.energycomponents.HeatPump;
-
- ResourceSet resSet = new ResourceSetImpl();
- Resource resource = resSet.getResource(URI.createURI("catalog.xml"), true);
- Collection allHeatPumps = EcoreUtil.getObjectsByType(
- resource.getContents(), EnCompPackage.eINSTANCE.getHeatPump());
-
-catalog.xml muss durch den richtigen Pfad zum XML-Katalog ersetzt werden.
-
-
-.Load XML Data Catalog and Access Corresponding Java Objects in Code
-
-*TBD*
-
-
-.Access from Python?
-
-*TBD*
+=== Create Insel Models with Handlebars Templates
+.Parameterization of blocks
-=== Create Insel Models with Handlebars Templates
-Handlebar templates to access data catalogs and create/parameterize textual simulation models.
+.Creation of submodels, e.g. for computing parameterized functions
-.Parameterization of blocks
-*TBD*
-
-.Creation of submodels, e.g. computing parameterized functions
+=== Accessing XML-Catalogs from Python
-*TBD*
diff --git a/ParameterCatalogs4TychoBuild.adoc b/ParameterCatalogs4Distribution.adoc
similarity index 95%
rename from ParameterCatalogs4TychoBuild.adoc
rename to ParameterCatalogs4Distribution.adoc
index 07606213e68bed8c64ceb448b2602eb4d70fd8fb..e6d15f3c68eebf85bb1d1308e841e9803e1e5daa 100644
--- a/ParameterCatalogs4TychoBuild.adoc
+++ b/ParameterCatalogs4Distribution.adoc
@@ -1,4 +1,4 @@
-== Build (Parameter Catalog) Applications with Eclipse Tycho
+== TBD: Distribution of Parameter Catalogs
Three plugins so for for the content and UI.
@@ -6,13 +6,9 @@ Missing: Deployable application and inclusion to third party libraries.
Building an application "around" the three plugins for Ecore data model and UI specification model.
-See template.
-
=== Create an Eclipse Application
-*TBD*
-
=== Use Maven and Tycho as Build System
@@ -55,16 +51,12 @@ image::InstallMaven3.gif[InstallMaven3, 400, role="thumb"]
."Mavenize" projects
-*TBD*
-
.Build and Deploy with Tycho
-*TBD*
.Add third party Java libraries
-*TBD*
"Correct" way to add third party Java libraries as plugins
@@ -73,9 +65,6 @@ Example Indriya
=== Deploy to P2 Repository
-*TBD*
-
=== Versioning and Collaboration
-*TBD*