# The ENVI-met Database System

## Introduction

Besides the two basic files needed for each simulation, the Area Input File .INX and the Simulation file .SIMX, ENVI-met needs to know a lot of additional information about different items used in your model such as surfaces types, soils, plants or emission sources in the model. These data are not stored in the Area Input file themself (exception: Packages), but in a database system.

To link the information stored in the Area input files with the different database information, ENVI-met uses a relational database: Each database entry is defined by a unique key, which has to be a two-sign alphanumerical ID in ENVI-met (e.g. “a0”). Any reference to a database entry, may it be in an Area Input file or some other table of the database is given by using this ID. For example, if you have defined a plant “a0” in your plant database, you can place it on a grid by setting the ID “a0” to this grid point.

The ENVI-met database system is a global system which is used for each simulation and all ENVI-met applications.

## Database Design

[]

Each ENVI-met database, System or User/Project, holds the following tables:

• Soils: Properties of different natural and artificial soils
• Soil Profiles:Different soil types as vertical sandwiches of soils
• Materials: Basic collection of different materials that can be use in walls
• Walls: Sets of building walls and roof composed out of 3 layers of different materials
• Single Walls: Sets of single and thin walls consisting of one material
• SimplePlants: Simple 1D plants such as grass.
• Sources: Emission profiles for different pollutant sources.

### System Database and User/Project Database: Basic Concept

ENVI-met uses two levels of databases, the System Database and the User/Project Database(s). The two levels and the databases are identical in their structure and format, but only the User/Project Database(s) can be edited by the user. The resulting set of Database items available in the simulation is a merge between the items defined in the System DB and those coming from the User/ Project DB.

If they all use different IDs, the resulting set will be simply the sum of the items in both databases with all items available. However, if you use the same ID for items in both the System DB and the User/Project DB, the user content in the User/Project DB will overwriten the System DB item.

In the example below, the System DB introduces 3 elements: AA, BB and CC. In the User DB, the elements BB and DD are defined (here in red to mark their orign). The final result of elements will be AA, BB, CC and DD in which BB and DD are the items defined in the User DB. The item BB in the System DB will be overwritten and is not available until the item of the same ID will be removed from the User DB.

[]

#### System Database

The System Database will be maintained by the model developers and is identical in all ENVI-met installations. The user is not supposed to do any changes to this database!. Moreover, this database will automatically be re-created with software updates, so any user-added content will be lost.

#### User Database

The User Database is the place where you can place all your personal data and settings. ENVI-met will not touch this database, even not when updating the software. However, you are responsible for the content of this database. If you add information that doesn't make sense e.g non-physical material properties, you will probably crash your simulation. The User Database is used for all projects unless you specifiy an individual project-centered database (see next paragraph).

#### Project Database

As said above, there is always one global user-editable database in the ENVI-met system that can be used in all simulations in all projects. However, if you have a lot of different projects or very specific projects, it might not be the best idea to store all the user-defined items in one big database. Especially if you want to adjust certian properties of items, e.g. soil materials, for certain simulations or projects, it might be undesirable that these material changes will effect all other simulations as well - which will be the case if edited in the global User Database.

For an easier handling of data, ENVI-met gives the option to specify an individual Project Database for each project. This Project database is structured in the same way as the User Database (and the System Database), but it will only be used in simulations within the assigned project. The usage of a Project Database is optional. If no Project Database is specified, the global User Database will be used.

### Database format and syntax

The ENVI-met database files are all stored in the EML format. Different to previous versions, all items and topics (soils, plants, wall,…) are stored in one big database file which is then organized in different tables. So the System Database is one file, the global User Database is another single file and -if used- the project based Database Files are also single files belonging to “their” projects.

As the database files can get very large, it is not recommended to edit them by hand. The ENVI-met Database Manager is designed to assist you in managing your database files and edit the different tables and datasets.

As EML is a self-describing format, the tags and items correspond to the described tables and data sets. Also there is no longer any fixed order in which the items need to appear in the files, so there is basically no need for further format descriptions above those given in the EML specifications and the description of the different database items as provided in the table descriptions.

### Database logic

Some of the tables of the database are linking relational to some more basic tables: Soil Profiles links to Soils to compose the vertical soil layer structure, Walls and Thin Walls link to Materials to define the materials they are built of.

As the user can only edit the User Database, there is a simple logic for managing the system and user database:

• All tables in the System Database only refer to items stored in tables of the System Database (we keep track of that)
• Tables in the User Database can refer either to items in the same User Database or to items stored in the System Database

The latter one makes it obvoius why any additions to the system should only be done in the User Database. The System Database will stay the same over the time (or kept compatible). That makes it sure that any user-defined items linking to System Databaye items will always work. User defined items might link to other user-defined items, but in this case they all need to be defined in the same database.

The project database completely replaces the User Database. In other words: Items stored in the global User Database will not be loaded and will not be available for projects using their own Project Database. The Database Manager provides serveral tools to copy content between the different database, so it should be easy to manage the data flow.

## The Database Manager

Although the database files follow the XML-standard, we highly recommend that you use our tool, the Database Manager, to organize the ENVI-met database.