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
Next revisionBoth sides next revision
filereference:edx_edi [2014/01/16 21:27] – [The EDX Metadata file] enviadminfilereference:edx_edi [2014/08/16 00:00] – [The EDT Binary file] enviadmin
Line 15: Line 15:
 **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 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. 
  
-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 dimensioans 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 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. 
  
  
Line 70: Line 70:
   * 3D facade files with 3 data for each grid point corresponding to the x-, y- and z-cell faces of the cell   * 3D facade 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_ 
-    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. 
Line 122: Line 125:
 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 whithout intepreting 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 infomrmation store before. 
  
  
-=== Grid spacing  <spacing_x> <spacing_y> <spacing_z> ===+=== Grid spacing:  <spacing_x> <spacing_y> <spacing_z> ===
 Defines the size of the individual grids in x-, y- and z- dimension. For each grid as given by the '' <nr_xdata> <nr_ydata>  <nr_zdata>'' tag, a grid size value needs to be defined.  Defines the size of the individual grids in x-, y- and z- dimension. For each grid as given by the '' <nr_xdata> <nr_ydata>  <nr_zdata>'' tag, a grid size value needs to be defined. 
  
Line 141: Line 144:
 </code> </code>
  
-The **variables** section defines the different information lyers 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 preceeding 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 covers 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 gird pont. 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 acount.
  
 === <nr_variables> === === <nr_variables> ===
Line 155: Line 158:
 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. 
  
 ==== Model Description ==== ==== Model Description ====
Line 174: Line 177:
 </code> </code>
      
-The **<modeldescription>** section desribes 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 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.
  
-Software like LEONADO 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 184: Line 187:
      <envi-met_version> ENVI-met V4.0 © Michael Bruse and team 1997-2014 </envi-met_version>      <envi-met_version> ENVI-met V4.0 © Michael Bruse and team 1997-2014 </envi-met_version>
      <envi-met_GUID> LORRAINE2_06.09.1985_20.13.18 </envi-met_GUID>      <envi-met_GUID> LORRAINE2_06.09.1985_20.13.18 </envi-met_GUID>
 +     <licenseholder> Marty MacFly </licenseholder>
   </envi-met_reference>   </envi-met_reference>
  
 </code> </code>
  
-The ENVI-met reference is added to kep track on which version the simulation was actually executed.+The ENVI-met reference is added to keep track on which version the simulation was actually executed.
  
 +In addition, the ''<envi-met_GUID>'' holds a reference to the computer and the time the simulation was started. This will be needed for distributed computing in the near future. 
 +The ''<licenseholder>'' tag watermarks the output data with the name of the license holder in case the professional version of ENVI-met, Biomet or other future products with special licenses is used.
  
-In addition, the ''<envi-met_GUID>'' holds a reference to the computer and the time the simulation was started. This will be neede for distributed computimg in the near future. +==== Additional Info ====
- +
-=== Additional Info ===+
  
 <code XML> <code XML>
Line 207: 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>