Tuflow

Naming Convention: Difference between revisions

Browse history interactively
← Older edit
Content deleted Content added
VisualWikitext
No edit summary
 
(3 intermediate revisions by one other user not shown)
Line 9:
Additionally, a sound naming convention can significantly reduce the time taken to locate files, especially in folders where hundreds of files are present, which may be the case for large modelling projects. Once a naming and numbering convention is adopted, then a <u>[[TUFLOW_Modelling_Log|modelling log]]</u> can more easily be kept.<br>
<br>
There is some simple advice on naming conventions in the <u>[https://downloadsdocs.tuflow.com/_archiveclassic-hpc/TUFLOWmanual/Releaseslatest/2018-03/TUFLOW%20Manual.2018-03.pdf 2018 TUFLOW Manual]</u>.<br>
MostCurrently, most modelling these days incorporates use of the TUFLOW scenario and event management feature. This allows for wildcards to be incorporated in the file name. <u>[[TUFLOW Example Models|Example models]]</u> are available which demonstrate Scenario/Event management. You can then set upA <u>[[ Run_TUFLOW_From_a_Batch-file#Looping_in_a_batch_file|batch file]]</u> can then be set up to run various scenario combinations from the one TUFLOW Control File (TCF).<br>
<br>
The below sections provide information on the recommended naming convention for clearly identifying different types of TUFLOW input files. Guidance is also provided on a version numbering convention for control and input files during model development.<br>
<br>
 
=Input File Type – Prefix Naming Conventions=
As the bulk of the data input to TUFLOW is via GIS layers, efficient management of these datasets is essential. Different TUFLOW input files require different GIS attributes. For example, an initial water level input file only requires a single attribute on the GIS file (which is the initial water level), whereas, a 1D channel has a number of attributes (channel type, inverts etc.). Differentiating between these TUFLOW file types is therefore essential.<br>
<br>
TUFLOW input files are given different recommended prefixes depending on their purpose. ThisAn example of this is demonstrated in the table below. (TableThe 2.4complete list of recommended prefixes can be found in the <u>[httphttps://wwwdocs.tuflow.com/Tuflow%20Documentation.aspx 2016classic-03-AEhpc/manual/latest/ TUFLOW Manual])</u>. The TCF command <font color="blue"><tt>Write Empty GIS Files</tt></font> can be used to automate the creation of the template (empty) files, which use these recommended prefixes. These empty files are created with the precise GIS file formats required for each input TUFLOW file. The <u>[[TUFLOW Empty Files]]</u> page provides a reference list of the template (empty) GIS files, the associated TUFLOW command and a basic description of their function.<br>
<br>▼
It is strongly recommended that the prefixes described in the table below be adhered to for all 1D and 2D GIS layers. This greatly enhances the data management efficiency and, importantly, allows for the differentiation of input files , making it easier for another modeller or reviewer to quickly interpret the model.<br>▼
<br>
▲It is strongly recommended that the prefixes described in the table<u>[https://docs.tuflow.com/classic-hpc/manual/latest/ TUFLOW belowManual]</u> be adhered to for all 1D and 2D GIS layers. This greatly enhances the data management efficiency and, importantly, allows for the differentiation of input files , making it easier for another modeller or reviewer to quickly interpret the model.<br>
 
{| class="wikitable" width="75%"
'''Note''' that the TUFLOW control files are structured to allow the majority of commands to be repeated and layered. Input file types of the same prefix may need to be used more than once. Hence, additional information such as a descriptor and a file version number is conventionally included in the input file name. An example of a typical file name for an input file is shown below: ▼
! style="background-color:#005581; font-weight:bold; color:white;" width=20%| GIS Data Type
! style="background-color:#005581; font-weight:bold; color:white;" width=20%| Suggested File Prefix
! style="background-color:#005581; font-weight:bold; color:white" width=60%| Description
|-
| style="text-align: left;" | 2D Boundaries and 2D/1D Links
| style="text-align: left;" | 2d_bc_ <br><br>(2d_hx_) <br><br>(2d_sx_)
|| Mandatory layer(s) defining the locations of 2D boundaries and 2D/1D dynamic links. For large models it may be wise to separate the boundary conditions from the 1D/2D links, in which case the 2d_bc prefix can be substituted with 2d_hx_ and 2d_sx. <br><br>Cell code values may also be defined in this layer.
|-
|}
▲<br>
 
▲'''Note''' that the TUFLOW control files are structured to allow the majority of commands to be repeated and layered. Input file types of the same prefix may need to be used more than once. Hence, additional information such as a descriptor and a file version number is conventionally included in the input file name. An example of a typical file name for an input file is shown below:
:Typical naming convention for a MIF formatted layer :
::'''<font color="red">FileTypePrefix</font>_<font color="green">FileDescriptor</font>_<font color="blue">FileVersion</font>.MIF'''
 
*GeoPackage:
:Example file name:
:* Database for the entire model:
::'''<font color="red">2d_bc</font>_<font color="green">CreekInflow</font>_<font color="blue">001</font>.MIF'''
:::'''ModelName'''_'''FileVersion'''.gpkg
:::'''M01'''_'''001'''.gpkg
:* Database for GIS layer (multiple geometry types):
:::'''FileTypePrefix'''_'''FileDescriptor'''_'''FileVersion'''.gpkg
:::'''2d_bc'''_'''CreekInflow'''_'''001'''.gpkg<br>
:* Database for GIS layer (single geometry type):
:::'''FileTypePrefix'''_'''FileDescriptor'''_'''FileVersion'''_'''GeometryType'''.gpkg
:::'''2d_bc'''_'''CreekInflow'''_'''001'''_'''L'''.gpkg<br>
:* GeoPackage Layer (within a database):
:::'''gpkgDatabaseName'''_'''GeometryType'''
:::2d_bc_CreekInflow_001.gpkg >> '''2d_bc_CreekInflow'''_'''L'''<br>
<br>
:For a shapefile layer, only a single geometry type (points, lines or regions) can be included in a shapefile. Therefore, for datasets made up of multiple geometries, for example points and lines two seperate files will be required. The suggested file naming convention for shapefiles therefore includes the geometry type (P for points, L for lines or R for regions). Typical naming convention for a Shapefile formatted layer :▼
::'''<font color="red">FileTypePrefix</font>_<font color="green">FileDescriptor</font>_<font color="blue">FileVersion</font>_<font color="purple">GeometryType</font>.SHP'''
 
*Shapefile layer:
:Example file name:
:::'''FileTypePrefix'''_'''FileDescriptor'''_'''FileVersion'''_'''GeometryType'''.shp
::'''<font color="red">2d_bc</font>_<font color="green">CreekInflow</font>_<font color="blue">001</font>_<font color="purple">L</font>.SHP'''
:::'''2d_bc'''_'''CreekInflow'''_'''001'''_'''L'''.shp<br>
 
▲:For a shapefile layer,<b>Note:</b> onlyOnly a single geometry type (points, lines or regions) can be included in a shapefile. ThereforeThus, for datasets made up of multiple geometries, for example points and lines, two seperateseparate files will be required. Therefore, Thethe suggested file naming convention for shapefiles therefore includes the geometry type (P for points, L for lines or R for regions). Typical naming convention for a Shapefile formatted layer :<br>
<br>
 
*MIF formatted layer:
:::'''FileTypePrefix'''_'''FileDescriptor'''_'''FileVersion'''.mif
:::'''2d_bc'''_'''CreekInflow'''_'''001'''.mif<br>
<br>
 
Many iterations of the same input file may be created as the model is developed. A suggested approach for the use of version numbering of input and control files is provided below.
Line 48 ⟶ 74:
*Similarly, if a change is made to any input GIS files listed in any of the control files, then the version number of that input file should be incremented, corresponding to the revised TCF version number. Numbering for a given input file is not necessarily sequential.
 
Generally, changes are made at the lowest level, i.e. the GIS input. That file, and all files in the hierarchy above it, are given a new version number consistent with the next TCF iteration. This provides an indication of at which point in the model development a GIS layer was introduced.
 
 
Each time a new element/s is introduced, the version number of the TCF is incremented. The above convention is demonstrated in the table below, showing file version numbering of input layers corresponding with the overarching control files. Each update is highlighted <font color="red">red</font>'''bold'''. The table below shows:
*whenWhen a new GIS layer is introduced or amendment made, a new TCF is created with the version number iterated up. The GIS layer is assigned the same version number as the TCF;
*theThe numbering of input layers doesn’t have to be sequential, as per the development Z shape and the 1d_nwk layers;
*modificationsModifications can be made in a number of the sub-control files for a given TCF increment, as per Model_005.tcf.
 
 
{| class="wikitable" width="100%"
Line 69 ⟶ 94:
| style="text-align: center;" | MODEL_001.tcf
| style="text-align: center;" | MODEL_001.tgc
|| gis\2d_loc_EG00_001_L.shp<br> gis\2d_code_001_R.shp<br> grid\DEM_2mLidar_01.asctif
| style="text-align: center;" | MODEL_001.tbc
|| gis\2d_bc_EG00_001_L.shp
Line 76 ⟶ 101:
|| Construct 2D only model with base topography.<br>
|-
| style="text-align: center;" | <font color="red">'''MODEL_002.tcf'''</font>
| style="text-align: center;" | <font color="red">'''MODEL_002.tgc''' </font>
|| gis\2d_loc_EG00_001_L.shp<br> gis\2d_code_001_R.shp<br> grid\DEM_2mLidar_001.asctif<br> <font color="red">'''gis\2d_zsh_Development_002_R.shp'''
| style="text-align: center;" | MODEL_001.tbc
|| gis\2d_bc_EG00_001_L.shp
Line 85 ⟶ 110:
|| Add topographic amendments for development.<br>
|-
| style="text-align: center;" | <font color="red">'''MODEL_003.tcf''' </font>
| style="text-align: center;" | MODEL_002.tgc
|| gis\2d_loc_EG00_001_L.shp<br> gis\2d_code_001_R.shp<br> grid\DEM_2mLidar_001.asctif<br> gis\2d_zsh_Development_002_R.shp
| style="text-align: center;" | MODEL_001.tbc
|| gis\2d_bc_EG00_001_L.shp
| style="text-align: center;" | <font color="red">'''MODEL_003.ecf'''</font>
|| <font color="red">'''1d_nwk_Pipes_003.shp'''</font>
|| Add 1D elements.
|-
| style="text-align: center;" | <font color="red">'''MODEL_004.tcf '''</font>
| style="text-align: center;" | MODEL_002.tgc
|| gis\2d_loc_EG00_001_L.shp<br> gis\2d_code_001_R.shp<br> grid\DEM_2mLidar_001.asctif<br> gis\2d_zsh_Development_002_R.shp
| style="text-align: center;" | <font color="red">'''MODEL_004.tbc'''</font>
|| gis\2d_bc_EG00_001_L.shp<br> <font color="red">'''gis\2f_rf_004_R2d_rf_004_R.shp''' </font>
| style="text-align: center;" | MODEL_003.ecf
|| 1d_nwk_003.shp
|| Add 2D rainfall polygon boundary condition.<br>
|-
| style="text-align: center;" | <font color="red">'''MODEL_005.tcf'''</font>
| style="text-align: center;" | <font color="red">'''MODEL_005.tgc''' </font>
|| gis\2d_loc_EG00_001_L.shp<br> gis\2d_code_001_R.shp<br> grid\DEM_2mLidar_001.asctif<br> <font color="red">'''gis\2d_zsh_Development_005_R.shp'''</font>
| style="text-align: center;" | MODEL_004.tbc
|| gis\2d_bc_EG00_001_L.shp<br> gis\2f_rf_004_R2d_rf_004_R.shp
| style="text-align: center;" | <font color="red">'''MODEL_005.ecf'''</font>
|| <font color="red">'''1d_nwk_Pipes_005.shp'''</font>
|| Make modifications to the original development + update the 1D elements.<br>
|-
|}
 
<br>
{{Tips Navigation
Retrieved from "https://wiki.tuflow.com/Naming_Convention"