A holistic microclimate model

You are here: Technical Model Webpage » filereference » The EDX/EDT file format

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
filereference:edx_edi [2014/07/15 16:22] – [ENVI-met Reference] enviadminfilereference:edx_edi [2023/01/05 20:06] (current) – enviadmin
Line 10: Line 10:
 ===== The EDX Metadata file ===== ===== The EDX Metadata file =====
  
-As the EDX files are [[filereference:fileformat|EML-based]], they are self-documenting and easy to extend for future uses. They follow up the old EDI files which did not provide these options and are therefore replaced. THE EDX files also provide enhanced information on the background of the data produced, e.g. in which simulation run and wheather they are normal data or intitial, check or panic data. +As the EDX files are [[filereference:fileformat|EML-based]], they are self-documenting and easy to extend for future uses. They follow up the old EDI files which did not provide these options and are therefore replaced. The EDX files also provide enhanced information on the background of the data produced, e.g. in which simulation run and wheather they are normal data or initial, check or panic data. 
-In the following scetions, the components of the EDX-File are described.+In the following sections, the components of the EDX-File are described.
  
-**Note:** All data stored withing the EDX files by ENVI-met are consistent. Several sections contain repeating (=redundant) information. While normally redundant information are seen as a design failure, here they serve a clear target: They allow a quick access on the raw data  without interpreting the thematic content of the file and its implication on the file format. +**Note:** All data stored within the EDX files by ENVI-met are consistent. Several sections contain repeating (=redundant) information. While normally redundant information are seen as a design failure, here they serve a clear target: They allow a quick access on the raw data  without interpreting the thematic content of the file and its implication on the file format. 
  
-Example: A surface flux file is always just 2-dimensional, hence storing its dimension as a seperate information is redundant. But some external programs may want to read the file, but will not understand the concept of a surface file. So they require an explict definition of the spatial dimensions of the file in terms of x-, y- and z-cells in order to work. +Example: A surface flux file is always just 2-dimensional, hence storing its dimension as a separate information is redundant. But some external programs may want to read the file, but will not understand the concept of a surface file. So they require an explicit definition of the spatial dimensions of the file in terms of x-, y- and z-cells in order to work. 
  
  
Line 31: Line 31:
 </code> </code>
  
-The **Header** of the file is non-simulation specific and includes version numbers and identifers as described in the [[filereference:fileformat|EML standards]]+The **Header** of the file is non-simulation specific and includes version numbers and identifiers as described in the [[filereference:fileformat|EML standards]]
  
  
Line 51: Line 51:
 </code> </code>
  
-The Data Descrition section of the EDX-file contains metadata on the general structure of the Data.+The Data Description section of the EDX-file contains metadata on the general structure of the Data.
 The items are: The items are:
 === <data_type> === === <data_type> ===
Line 65: Line 65:
 </code> </code>
  
-The ''<data_type>'' itemes defines the general type of the data file. For the moment, there are only 3 different typologies of data files:+The ''<data_type>'' items defines the general type of the data file. For the moment, there are only 3 different typologies of data files:
   * 2D raster files with one data for each grid point (basically a special case of a 3D file with just one z- coordinate)   * 2D raster files with one data for each grid point (basically a special case of a 3D file with just one z- coordinate)
   * 3D raster files with one data for each grid point    * 3D raster files with one data for each grid point 
-  * 3D facade files with 3 data for each grid point corresponding to the x-, y- and z-cell faces of the cell+  * 3D façade files with 3 data for each grid point corresponding to the x-, y- and z-cell faces of the cell
  
-In the example goven above, we obviously have a 2D raster file to deal with....+In the example given above, we obviously have a 2D raster file to deal with....
 **Note: More type are up to come** **Note: More type are up to come**
  
Line 78: Line 78:
 type type
   tSimFileContent = (   tSimFileContent = (
-    fcUnknown = 0, // undef +    fcUnknown = 0, // undefined format 
-    fcAtmosphere = 1, // 3d atmosphere data _AT_+    fcAtmosphere = 1, // 3D atmosphere data _AT_
     fcSurface = 2, // surface data _FX_     fcSurface = 2, // surface data _FX_
     fcSoil = 3, // soil data  _SO_     fcSoil = 3, // soil data  _SO_
Line 85: Line 85:
     fcBiomet = 5, // biomet _BIO_     fcBiomet = 5, // biomet _BIO_
     fcVegetation = 6, // vegetation _VEG_     fcVegetation = 6, // vegetation _VEG_
-    fcFacade = 7, // building data _BLDG_ +    fcFacade = 7, // building facade data _FAC_ (dynamic) 
-    fcSolarAccess = 8, // solar access _SA_+    fcSolarAccess = 8, // 2D solar access _SA_
     fcFacadeStatic = 9, // constant building data _BLDG_     fcFacadeStatic = 9, // constant building data _BLDG_
-    fcFacadeSolarAccess = 10 // facade solar access data _SAFAC_+    fcFacadeSolarAccess = 10, // facade solar access data _SAFAC_ 
 +    fcRadiation = 11, // radiation data _RD_ 
 +    fcViewScape = 12, // view projections  _IVS_ 
 +    fcPhotocat = 13   // photocatalytic data _PHX_
     );     );
-    </code>+        </code>
  
-The ''<data_content>'' tag describes the thematic content of the file. Basically, it is not needed to read and display the values, but it increases the information feedback if one knows, what is in the file. +The ''<data_content>'' tag describes the thematic content of the file. Basically, it is not needed to read and display the values, but it increases the information feedback if one knows, what is in the file (see [[http://www.envi-met.info/hg2e/doku.php?id=filereference:output:start]]. 
  
 The file content in ENVI-met is referenced in more than one way:  The file content in ENVI-met is referenced in more than one way: 
-  - By the **folder** where it is stored. All output files are organised in different folders such as ''atmosphere'' or ''soil''  to make clear what is the content. This is a very unsafe identifer as files are moved around frequently. +  - By the **folder** where it is stored. All output files are organised in different folders such as ''atmosphere'' or ''soil''  to make clear what is the content (see . This is a very unsafe identifier as files are moved around frequently. 
-  - By the **''filename''**.  Each file produced by ENVI-met holds a unique identifer such as ''_AT_'' for atmospheric data (see above).  In versions before 4.0 this was the only identifer to make clear what actually is stored in the file as file might be moved out of their original folders. +  - By the **''filename''**.  Each file produced by ENVI-met holds a unique identifier such as ''_AT_'' for atmospheric data (see above).  In versions before 4.0 this was the only identifier to make clear what actually is stored in the file as file might be moved out of their original folders. 
-  - By the **''<data_content>''** tag. In Version V4 we have added a more explict information tag about the content of the file. This replaces any file analyis for the identifer mentioned above which might be gone by renaming a file. +  - By the **''<data_content>''** tag. In Version V4 we have added a more explicit information tag about the content of the file. This replaces any file analysis for the identifier mentioned above which might be gone by renaming a file. 
  
 === <data_health_status> === === <data_health_status> ===
Line 120: Line 123:
 ===  <data_spatial_dim> === ===  <data_spatial_dim> ===
  
-The ''<data_spatial_dim>'' is a redundant information on the spatial layout of the binary file. However, it is designed to easily interpret the file whithout intepreting the ''<data_type>'' tag.+The ''<data_spatial_dim>'' is a redundant information on the spatial layout of the binary file. However, it is designed to easily interpret the file without interpreting the ''<data_type>'' tag.
  
 === Dimensions:  <nr_xdata> <nr_ydata>  <nr_zdata> === === Dimensions:  <nr_xdata> <nr_ydata>  <nr_zdata> ===
-Defines the matrix layout of the binary files. It is again, to some extent, a repetition to the infomrmation store before. +Defines the matrix layout of the binary files. It is again, to some extent, a repetition to the information store before. 
  
  
Line 143: Line 146:
 The **variables** section defines the different information layers stored in the binary EDT file.  The **variables** section defines the different information layers stored in the binary EDT file. 
  
-While the preceeding section were used to interpret the format of the file, this section defines the information stored for each grid. +While the preceding section were used to interpret the format of the file, this section defines the information stored for each grid. 
  
 ===  <Data_per_variable> === ===  <Data_per_variable> ===
 The ''<Data_per_variable>'' tag sets the amount of information that is stored for each grid. It duplicates the ''<data_type>'' tag to some extent. The ''<Data_per_variable>'' tag sets the amount of information that is stored for each grid. It duplicates the ''<data_type>'' tag to some extent.
-In most of the cases, there is just one data set for each grid point. But for the 3D data of buildings coded with ''ft3DFacade = 3''  there are actually 3 data for each grid that must be taken into acount.+In most of the cases, there is just one data set for each grid point. But for the 3D data of buildings coded with ''ft3DFacade = 3''  there are actually 3 data for each grid that must be taken into account.
  
 === <nr_variables> === === <nr_variables> ===
Line 153: Line 156:
  
 === <name_variables>=== === <name_variables>===
-Lists the name of the variables as a comma-seperated list. +Lists the name of the variables as a comma seperated list. 
  
 **Please note**: LEONARDO will interpret information given in "( )" as UNITS for the variable and will place it on the correct space in legends and other map layout features.  **Please note**: LEONARDO will interpret information given in "( )" as UNITS for the variable and will place it on the correct space in legends and other map layout features. 
Line 174: Line 177:
 </code> </code>
      
-The **<modeldescription>** section desribes the simulation time and the geographical details of the model area used in the simulation. It is not required to decode the .EDT file, but it is of great help when analysing simulation sets coming for external sources. The data fields corresponds to the general model setings and hence they are not explainded in detail again.+The **<modeldescription>** section describes the simulation time and the geographical details of the model area used in the simulation. It is not required to decode the .EDT file, but it is of great help when analysing simulation sets coming for external sources. The data fields corresponds to the general model settings and hence they are not explained in detail again.
  
 Software like LEONARDO will interpret the ''<modeldescription>'' section to allow a project-orientated user interface. Software like LEONARDO will interpret the ''<modeldescription>'' section to allow a project-orientated user interface.
Line 208: Line 211:
  
 The EDT file just holds raw binary data in Intel Float format (single precision). In order to be decoded properly, the associated metadata from the EDX file must be evaluated correctly. The EDT file just holds raw binary data in Intel Float format (single precision). In order to be decoded properly, the associated metadata from the EDX file must be evaluated correctly.
-The basic structure of the EDT file is a follows: +The basic structure of the EDT file created using the logic shown below:
- +
- +
-The file are written with the following loop logic+
 <code Pascal> <code Pascal>
  
Line 219: Line 219:
       For y:=0 to YY-1 do       For y:=0 to YY-1 do
         For x:=0 to XX-1 do         For x:=0 to XX-1 do
-          For n:=0 to D do+          For n:=0 to D-1 do
             Write Variable[i].Value[x][y][z][n];             Write Variable[i].Value[x][y][z][n];
  end;  end;
 </code> </code>
  
-Here ''XX'',''YY'' and ''ZZ'' are the dimensions of the model domain started counting at x=0,y=0,z=0 at the **lower left corner** of the model. ''D'' is the variable dimension of the file. For most files, ''D'' is 1 (=one data value for each grid coordinate and variable), for facade files e.g. ''D'' is 3 (= 3 values for each grid for the left x-, front y- and bottom z- face. The values for the right x-, rear y- and top z-face are stored in the neighbour cells).+Here ''XX'',''YY'' and ''ZZ'' are the dimensions of the model domain started counting at x=0,y=0,z=0 at the **lower left corner** of the model. ''D'' is the variable dimension of the file. For most files, ''D'' is 1 (=one data value for each grid coordinate and variable), for façade files e.g. ''D'' is 3 (= 3 values for each grid for the left x-, front y- and bottom z- face. The values for the right x-, rear y- and top z-face are stored in the neighbour cells). 
 + 
 +In addition, the 3D files for building façades hold **one** field  of dimension 1 at the very beginning:  
 +<code Pascal> 
 + 
 +    For z:= 0 to ZZ-1 do 
 +      For y:=0 to YY-1 do 
 +        For x:=0 to XX-1 do 
 +             Write ObjectData[x][y][z]; 
 + 
 +</code> 
 +This field holds the general Object information like in the atmosphere files marking the position of buildings, plants, DEM and sources. 
  
 +==== No Data Flag ====
  
 +In all ENVI-met output files, the value of **-999** represents the "No Data" flag.  Why certain grids do not carry valid data depends mainly on the data itself and how it was generated, so no general explanation can be given here. In any case, data flagged with a "No Data" value should not be included in any further data analysis or visualisation.  
  
 +===== Reading EDX/EDT files =====
 +Using the information above, it should be easy to read ENVI-met output files from all programming languages.
 +A good tutorial on how to use Python with NumPy can be found here: [[|Blog: Reading ENVI-met Files]].
 +Also check out the [[apps:datastudio:start|]] page for more information.